Healthcare Transaction Facilitation Platform Apparatuses, Methods and Systems

ABSTRACT

The Healthcare Transaction Facilitation Platform Apparatuses, Methods and Systems (“HTFP”) transforms payment file and EOP data inputs via HTFP components into ACH request, card generation request, card payment request, ACH CCD+ request, and EOP file outputs. A card generation request associated with a payment to a provider may be obtained via the card generating component via a network. A payment amount and a re-association trace number may be determined by parsing the card generation request. A card for the payment may be generated and the card may be associated with the payment amount and the re-association trace number. A card payment processing request associated with the card may be sent. The card payment processing request may be obtained via the card payment processing component. A Level 3 card payment request that includes the payment amount and the re-association trace number may be generated. A payment request route associated with the card may be determined and the Level 3 card payment request may be pushed via the payment request route.

This application for letters patent disclosure document describesinventive aspects that include various novel innovations (hereinafter“disclosure”) and contains material that is subject to copyright, maskwork, and/or other intellectual property protection. The respectiveowners of such intellectual property have no objection to the facsimilereproduction of the disclosure by anyone as it appears in publishedPatent Office file/records, but otherwise reserve all rights.

PRIORITY CLAIM

Applicant hereby claims benefit to priority under 35 USC § 119 as anon-provisional conversion of: US provisional patent application serialno. 61/912,759, filed Dec. 6, 2013, entitled “Methods and Systems forPaying Healthcare Providers Using Multi-use Credit Cards and PushPayment Processing Techniques,” (attorney docket no. 93635-895114).

Applicant hereby claims benefit to priority under 35 USC § 119 as anon-provisional conversion of: US provisional patent application serialno. 62/055,556, filed Sep. 25, 2014, entitled “Healthcare TransactionFacilitation Platform Apparatuses, Methods And Systems,” (attorneydocket no. Payplus0001PV2).

Applicant hereby claims benefit to priority under 35 USC § 120 as acontinuation-in-part of: US patent application Ser. No. 13/495,056,filed Jun. 13, 2012, entitled “Systems and Methods for Managing Paymentsand Related Payment Information for Healthcare Providers,” (attorneydocket no. 93635-831181); and which in turn claims benefit to priorityunder 35 USC § 119 as a non-provisional conversion of: US provisionalpatent application Ser. No. 61/498,021, filed Jun. 17, 2011, entitled“System and Method for Payment Facilitation,” and claims benefit topriority under 35 USC § 119 as a non-provisional conversion of: USprovisional patent application Ser. No. 61/604,722, filed Feb. 29, 2012,entitled “System and Methods for Managing Payments for Medical Servicesand Providing Payment Information.”

The entire contents of the aforementioned applications are hereinexpressly incorporated by reference.

FIELD

The present innovations generally address payment platforms, and moreparticularly, include Healthcare Transaction Facilitation PlatformApparatuses, Methods and Systems.

BACKGROUND

Medical service providers are often paid for their services by payorsother than a patient. For example, insurance companies, self-fundedcorporations, unions, and other third-party payors may adjudicate claimsin accordance with a plan of benefits for their plan members (theinsured patient). Payment from patients is typically accepted in theform of cash, check, or credit/debit card.

BRIEF DESCRIPTION OF THE DRAWINGS

Appendices and/or drawings illustrating various, non-limiting, example,innovative aspects of the Healthcare Transaction Facilitation PlatformApparatuses, Methods and Systems (hereinafter “HTFP”) disclosure,include:

FIGS. 1A-1C show a datagraph diagram illustrating embodiments of a dataflow for the HTFP;

FIG. 2 shows a logic flow diagram illustrating embodiments of a paymentfile processing (PFP) component for the HTFP;

FIG. 3 shows a logic flow diagram illustrating embodiments of a cardgenerating (CG) component for the HTFP;

FIG. 4 shows a logic flow diagram illustrating embodiments of a cardpayment processing (CPP) component for the HTFP;

FIG. 5 shows a logic flow diagram illustrating embodiments of a paymentsettling (PS) component for the HTFP;

FIG. 6 shows a logic flow diagram illustrating embodiments of an EOP(Explanation of Payment) file delivering (EFD) component for the HTFP;

FIG. 7 shows a screenshot diagram illustrating embodiments of a paymentfile for the HTFP;

FIG. 8 shows a screenshot diagram illustrating embodiments of a cardgeneration request for the HTFP;

FIG. 9 shows a screenshot diagram illustrating embodiments of an ACHCCD+ payment request for the HTFP;

FIG. 10 shows a screenshot diagram illustrating embodiments of an EOPfile for the HTFP;

FIG. 11 shows a block diagram illustrating embodiments of a HTFPcontroller;

FIGS. 12-33 show block diagrams illustrating alternative embodiments forthe HTFP;

Generally, the leading number of each citation number within thedrawings indicates the figure in which that citation number isintroduced and/or detailed. As such, a detailed discussion of citationnumber 101 would be found and/or introduced in FIG. 1. Citation number201 is introduced in FIG. 2, etc. Any citation and/or reference numbersare not necessarily sequences but rather just example orders that may berearranged and other orders are contemplated.

DETAILED DESCRIPTION

The Healthcare Transaction Facilitation Platform Apparatuses, Methodsand Systems (hereinafter “HTFP”) transforms payment file and EOP datainputs, via HTFP components (e.g., PFP, CG, CPP, PS, EFD, etc.), intoACH request, card generation request, card payment request, ACH CCD+request, and EOP file outputs. The HTFP components, in variousembodiments, implement advantageous features as set forth below.

Introduction

The HTFP facilitates payments between a payor and a provider. Doctors,dentists, and other medical service providers receive checks and otherpayments and may identify payments in an office practice managementsystem. Such providers may also receive an explanation of benefits orexplanation of payment which may provide information allowing them toapply the payment to an insured patient's account. Providers may acceptpayment from patients by credit card or debit card (such as VISA™,Mastercard™ and AmericanExpress™) using credit card machines orterminals which are used to transfer funds from a bank associated withthe patient's card or acquirer bank to a merchant account associatedwith the particular machine/terminal The In one embodiment, the HTFPspecifies that, upon request by a provider, a payor should comply withan HTFP payment process, which in one embodiment, may be made compatiblewith the Patient Protection and Affordable Care Act (ACA). This mayinclude providing an Electronic Funds Transfer (EFT) payment as well asa compliant Explanation of Payment (EOP) data file (e.g., an 835 datafile), and utilizing a re-association trace number (TRN) to link the EFTpayment and the EOP data file. The HTFP Automated Clearinghouse (ACH) asthe EFT payment transaction type and specified ACH CCD+ format may beused to transfer the TRN when making a payment. It should be noted thatin one embodiment, that the CCD+ format may note that the transaction ishealthcare related (e.g., having a NACHA compliant entry where the CCDentry will include the value of “HCCLAIMPMT”).

In one embodiment, the HTFP processes card payments at Level 3 and makespayments using ACH CCD+ format to make card payments compatible with ACApayment forms. In another embodiment, the HTFP pushes payments so that aprovider does not have to access the provider's card machine to receivepayments. In yet another embodiment, the HTFP may facilitate the use ofa reloadable card compliant which the HTFP makes compatible with ACApayment forms.

HTFP

FIGS. 1A-1C show a datagraph diagram illustrating embodiments of a dataflow for the HTFP. In FIGS. 1A-1C, dashed lines indicate data flowelements that may be more likely to be optional. In FIG. 1A, a payorserver 102 may send a payment file 131 to a HTFP server 104. In oneembodiment, a payor may include any entity that processes medical claimpayments for some form of an insured or self-funded benefit plan, whichmay include entities such as insurance companies, self-administeredemployer health plans, third party administrators, health and welfareplans, and/or the like. In one implementation, the payment file mayinclude details regarding one or more payments from the payor to aprovider, and may include (e.g., for each payment) data such as apayment amount, a provider's details (e.g., a provider's name, aprovider's tax identification number (TIN), a provider's address), thepayor's details, a TRN associated with a payment, and/or the like. SeeFIG. 7 for an example of a payment file. In one embodiment, a providermay include a healthcare entity that performs medical treatments andbills for services (e.g., to a payor, to a patient, to both a payor anda patient). It is to be understood that while some embodiments describeprocessing the one or more payments in the payment file individually,the one or more payments in the payment file may be processed inaggregate (e.g., in one or more batches). In various implementations,the one or more payments in the payment file may be processed in realtime, on demand, asynchronously, concurrently, in parallel,simultaneously, synchronously, and/or the like. The payment file may beprocessed by a payment file processing (PFP) component 135. See FIG. 2for additional details regarding the PFP component.

The HTFP server may send an ACH request 139 associated with a payment(e.g., an individual payment, a batch of payments) to an issuer bank106. The ACH request may instruct the issuer bank to obtain fundsassociated with the payment from a payor bank 108. For example, if thepayment indicates that the payor (e.g., Health Plan) is sending apayment of $4,900.42 to the provider (e.g., ABC Healthcare Provider),the ACH request may be sent to the issuer's bank to obtain $4,900.42from the Health Plan's bank In one implementation, the ACH request mayinclude data such as the payment amount, the payor's details (e.g.,payor bank identifier, payor account number), issuer details (e.g.,issuer name, issuer account number), and/or the like. For example, theACH request may be formatted according to the eXtensible Markup Language(XML). An example ACH request, substantially in the form of a (Secure)Hypertext Transfer Protocol (HTTP(S)) POST message includingXML-formatted data, is provided below:

  POST /ACH_request.php HTTP/1.1 Host: www.server.com Content-Type:Application/XML Content-Length: 667 <?XML version =“1.0” encoding=“UTF-8”?> <ACH_request> <request_identifier>ID_request_1</request_identifier> <payment_amount>$4,900.42</payment_amount>  <from>  <institution_identifier>Payor Bank</institution_identifier>  <account_number>Payor's account number</account_number>  </from  <to>  <recipient_name>Issuer name</recipient_name>  <account_number>Issuer's account number</account_number>  </to></ACH_request>

The issuer bank may send an ACH payment request 143 to the payor bankThe ACH payment request may instruct the payor bank to provide fundsassociated with the payment to the issuer bank For example, the ACHpayment request may instruct the Health Plan's bank to send $4,900.42 tothe issuer's bank. In one implementation, the ACH payment request may besent using a standard ACH CCD format.

The payor bank may send an ACH payment 147 to the issuer bank Forexample, the payor's bank may send $4,900.42 to the issuer's bank In oneimplementation, the ACH payment may be sent using a standard ACH CCDformat. In some embodiments, the issuer bank may send a paymentconfirmation 151 to the HTFP server. The payment confirmation may beused to inform the HTFP server that funds have been received. Forexample, the payment confirmation may be formatted according to the XML.An example payment confirmation, substantially in the form of a HTTP(S)POST message including XML-formatted data, is provided below:

  POST /payment_confirmation.php HTTP/1.1 Host: www.server.comContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding =“UTF-8”?> <payment_confirmation> <request_identifier>ID_request_1</request_identifier>  <status>paymentreceived</status> </payment_confirmation>

The HTFP server may send a card generation request 155 to an issuerserver 110. In one embodiment, an issuer may generate cards and/orprocess card transactions. The issuer may have a contractualrelationship with the issuer bank, which may be a sponsoring bank thatallows the issuer access to a card payment network. In oneimplementation, the card generation request may include data such as theTRN associated with the payment, the payment amount, the provider'sdetails, the payor's details, and/or the like. See FIG. 8 for an exampleof a card generation request. The card generation request may instructthe issuer to generate a card and/or process a card transaction tofacilitate the payment. In various embodiments, a card may be a creditcard, a stored value card, a debit card, and/or the like, and may bevirtual or physical. The card generation request may be processed by acard generating (CG) component 159 and/or by a card payment processing(CPP) component 163. See FIG. 3 for additional details regarding the CGcomponent. See FIG. 4 for additional details regarding the CPPcomponent.

In one embodiment, the data flow may proceed as shown in FIG. 1B1. InFIG. 1B1, the issuer server may send a card payment request 167 to anacquirer server 116. In one embodiment, an acquirer may process and/orsettle card transactions for the provider. The acquirer may have acontractual relationship with an acquirer bank, which may be asponsoring bank that allows the acquirer access to a card paymentnetwork. For example, the card payment request may instruct the acquirerto process a card payment of $4,900.42 to the provider using the cardgenerated by the issuer. In one implementation, the card payment requestmay be a Level 3 processing request and may include data such as issuerdata (e.g., card number, card expiration date, card CVV code), paymentdata (e.g., payment amount, payment date), provider data (e.g.,provider's name, provider's address, provider's TIN), payor data (e.g.,payor's name, payor's address, payor's TIN), the TRN associated with thepayment, and/or the like. For example, the card payment request may beformatted according to the XML. An example card payment request,substantially in the form of a HTTP(S) POST message includingXML-formatted data, is provided below:

  POST /card_payment_request.php HTTP/1.1 Host: www.server.comContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding = “UTF-8”?> <card_payment_request> <request_identifier>ID_request_2</request_identifier> <card_number>0000-0000-0000-0001>  <card_CVV>123</card_CVV> <card_expiration_date>MM/YY</card_expiration_date> <payment_amount>$4,900.42</payment_amount>  <provider_name>ABCHealthcare Provider</provider_name> <provider_TIN>111111111</provider_TIN> <TRN>1|2262064|1452579291|123456789</TRN> </card_payment_request>

The acquirer server may send an interchange rate request 171 to apayment network 112. In one embodiment, a payment network may be a cardnetwork such as MasterCard, Visa, Discover, American Express, and/or thelike. In one implementation, the acquirer server may calculate aninterchange rate associated with the provider. The interchange rate is afee paid by the provider when a card payment is processed and mayinclude fees paid to the payment network, fees paid to the issuer of thecard, fees paid to the acquirer, and/or the like. In someimplementations, a business service arrangement (BSA) may be set up(e.g., to offer the provider a lower interchange rate) such that when acard payment associated with the provider's merchant identifier (MID) issent for processing, the MID links the payment to the appropriate BSAinterchange rate schedule. In some implementations, the issuer and theacquirer may be the same entity facilitating a lower interchange ratefor the provider (e.g., due to increased negotiation leverage with thepayment network in setting up the BSA, due to better cost and/orprofitability structure). The interchange rate request may instruct thepayment network to process the card payment at the calculatedinterchange rate. For example, the interchange rate request may beformatted according to the XML. An example interchange rate request,substantially in the form of a HTTP(S) POST message includingXML-formatted data, is provided below:

  POST /interchange_rate_request.php HTTP/1.1 Host: www.server.comContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding = “UTF-8”?> <interchange_rate_request> <request_identifier>ID_request_3</request_identifier> <card_number>0000-0000-0000-0001>  <card_CVV>123</card_CVV> <card_expiration_date>MM/YY</card_expiration_date> <payment_amount>$4,900.42</payment_amount>  <provider_name>ABCHealthcare Provider</provider_name> <provider_TIN>111111111</provider_TIN> <TRN>1|2262064|1452579291|123456789</TRN>  <MID>ID_Merchant1</MID> <interchange_rate>2%</interchange_rate> </interchange_rate_request>

The payment network may send an interchange rate response 173 to theacquirer server. In one embodiment, the interchange rate response mayconfirm the interchange rate specified for the transaction. For example,the interchange rate response may be formatted according to the XML. Anexample interchange rate response, substantially in the form of aHTTP(S) POST message including XML-formatted data, is provided below:

  POST /interchange_rate_response.php HTTP/1.1 Host: www.server.comContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding = “UTF-8”?> <interchange_rate_response> <response_identifier>ID_response_3</response_identifier> <request_identifier>ID_request_3</request_identifier> <interchange_rate>2%</interchange_rate>  <status>OK</status></interchange_rate_response>

In another embodiment, the interchange rate response may specify adifferent interchange rate calculated by the payment network for thetransaction. For example, the interchange rate response may be formattedaccording to the XML. An example interchange rate response,substantially in the form of a HTTP(S) POST message includingXML-formatted data, is provided below:

  POST /interchange_rate_response.php HTTP/1.1 Host: www.server.comContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding = “UTF-8”?> <interchange_rate_response> <response_identifier>ID_response_3</response_identifier> <request_identifier>ID_request_3</request_identifier> <interchange_rate>2.5%</interchange_rate> <status>Recalculated</status>  <calculation_details>Calculationdetails</calculation_details> </interchange_rate_response>

The payment network may send an ACH payment request 175 to the issuerbank The ACH payment request may instruct the issuer bank to providefunds associated with the payment to the payment network. For example,the ACH payment request may instruct the issuer's bank to send $4,900.42to the payment network. In one implementation, the ACH payment requestmay be sent using a standard ACH CCD format. The payment network maysend an ACH payment 177 to an acquirer bank 114. For example, thepayment network may send $4,900.42 to the acquirer's bank In anotherexample, the payment network may send $4,900.42 less the interchangerate (e.g., less a portion of the interchange rate, less the entireinterchange rate) to the acquirer's bank In one implementation, the ACHpayment may be sent using a standard ACH CCD format. In someimplementations, the payment network may send the ACH payment requestand the ACH payment in near real time. In some implementations, thepayment network may send the ACH payment request and/or the ACH paymentin a batch with other transactions. The issuer bank may send an ACHpayment 179 to the payment network. For example, the issuer's bank maysend $4,900.42 to the payment network. In one implementation, the ACHpayment may be sent using a standard ACH CCD format. In someembodiments, the acquirer bank may send a payment confirmation 181 tothe acquirer server. The payment confirmation may be used to inform theacquirer server that funds have been received. For example, the paymentconfirmation may be formatted according to the XML.

In another embodiment, the data flow may proceed as shown in FIG. 1B2.In FIG. 1B2, the issuer server may send a card payment request 167 tothe payment network 112. For example, the card payment request mayinstruct the payment network to process a card payment of $4,900.42 tothe provider using the card generated by the issuer. In oneimplementation, the payment network may calculate the interchange rateassociated with the transaction (e.g., based on the provider's MID). Inone implementation, the card payment request may be a Level 3 processingrequest and may include data such as issuer data (e.g., card number,card expiration date, card CVV code), payment data (e.g., paymentamount, payment date), provider data (e.g., provider's name, provider'saddress, provider's TIN), payor data (e.g., payor's name, payor'saddress, payor's TIN), the TRN associated with the payment, and/or thelike. For example, the card payment request may be formatted accordingto the XML. An example card payment request, substantially in the formof a HTTP(S) POST message including XML-formatted data, is providedbelow:

  POST /card_payment_request.php HTTP/1.1 Host: www.server.comContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding = “UTF-8”?> <card_payment_request> <request_identifier>ID_request_2</request_identifier> <card_number>0000-0000-0000-0001>  <card_CVV>123</card_CVV> <card_expiration_date>MM/YY</card_expiration_date> <payment_amount>$4,900.42</payment_amount>  <provider_name>ABCHealthcare Provider</provider_name> <provider_TIN>111111111</provider_TIN> <TRN>1|2262064|1452579291|123456789</TRN>  <MID>ID_Merchant1</MID></card_payment_request>

In some embodiments, the payment network may send a payment confirmation171 to the acquirer server. The payment confirmation may be used toinform the acquirer server that the card payment has been received. Forexample, the payment confirmation may be formatted according to the XML.An example payment confirmation, substantially in the form of a HTTP(S)POST message including XML-formatted data, is provided below:

  POST /payment_confirmation.php HTTP/1.1 Host: www.server.comContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding = “UTF-8”?> <payment_confirmation> <request_identifier>ID_request_2</request_identifier> <card_number>0000-0000-0000-0001>  <card_CVV>123</card_CVV> <card_expiration_date>MM/YY</card_expiration_date> <payment_amount>$4,900.42</payment_amount>  <provider_name>ABCHealthcare Provider</provider_name> <provider_TIN>111111111</provider_TIN> <TRN>1|2262064|1452579291|123456789</TRN>  <MID>ID_Merchant1</MID> <interchange_rate>2%</interchange_rate>  <status>card paymentreceived</status> </payment_confirmation>

The payment network may send an ACH payment request 175 to the issuerbank The ACH payment request may instruct the issuer bank to providefunds associated with the payment to the payment network. For example,the ACH payment request may instruct the issuer's bank to send $4,900.42to the payment network. In one implementation, the ACH payment requestmay be sent using a standard ACH CCD format. The payment network maysend an ACH payment 177 to the acquirer bank For example, the paymentnetwork may send $4,900.42 to the acquirer's bank In another example,the payment network may send $4,900.42 less the interchange rate to theacquirer's bank In one implementation, the ACH payment may be sent usinga standard ACH CCD format. In some implementations, the payment networkmay send the ACH payment request and the ACH payment in near real time.In some implementations, the payment network may send the ACH paymentrequest and/or the ACH payment in a batch with other transactions. Theissuer bank may send an ACH payment 179 to the payment network. Forexample, the issuer's bank may send $4,900.42 to the payment network. Inone implementation, the ACH payment may be sent using a standard ACH CCDformat. In some embodiments, the acquirer bank may send a paymentconfirmation 181 to the acquirer server. The payment confirmation may beused to inform the acquirer server that funds have been received. Forexample, the payment confirmation may be formatted according to the XML.An example payment confirmation, substantially in the form of a HTTP(S)POST message including XML-formatted data, is provided below:

  POST /payment_confirmation.php HTTP/1.1 Host: www.server.comContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding = “UTF-8”?> <payment_confirmation> <request_identifier>ID_request_3</request_identifier>  <status>paymentreceived</status> </payment_confirmation>

In FIG. 1C, the payment may be settled by a payment settling (PS)component 183. See FIG. 5 for additional details regarding the PScomponent. The acquirer server may send an ACH CCD+ payment request 187to the acquirer bank In one implementation, the ACH CCD+ payment requestmay include data such as the TRN associated with the payment, thepayment amount, the provider's details, the payor's details, and/or thelike. For example, the ACH CCD+ payment request may be sent using ACHCCD+ format. See FIG. 9 for an example of ACH CCD+ format. In anotherexample, the ACH CCD+ payment request may be sent using an equivalentformat (e.g., formatted as an XML file). The ACH CCD+ payment requestmay instruct the acquirer bank to provide funds associated with thepayment to a provider bank 118. For example, the ACH CCD+ paymentrequest may instruct the acquirer's bank to send $4,900.42 to theprovider's bank In another example, the ACH CCD+ payment request mayinstruct the acquirer's bank to send $4,900.42 less the interchange rateto the provider's bank In some implementations, the acquirer server maysend the ACH CCD+ payment request in a batch with other transactions.

The acquirer bank may send an ACH CCD+ payment 189 to the provider bank.For example, the acquirer bank may send $4,900.42 to the provider's bankIn another example, the acquirer bank may send $4,900.42 less theinterchange rate to the provider's bank. In one implementation, the ACHCCD+ payment may be sent using ACH CCD+ format.

As shown in FIG. 1A, the payor server may send EOP data 191 to the HTFPserver. In one implementation, the EOP data may include EOP files forone or more payments from the payor to the provider, and may include(e.g., for each payment) data such as the TRN associated with thepayment, the payment amount, the provider's details, the payor'sdetails, details regarding the payment (e.g., claim number, date ofservice, patient identifier, amount billed, discount amount, deductibleamount, coinsurance amount, allowed payment amount, reasons forspecified amounts), and/or the like. See FIG. 10 for an example of anEOP file. As shown in FIG. 1C, the EOP data may be processed by an EOPfile delivering (EFD) component 195. See FIG. 6 for additional detailsregarding the EFD component. The HTFP server may deliver an EOP file 199to the provider. For example, the HTFP server may upload the EOP file toa provider server 120. In some implementations, the HTFP server maytransmit the EOP file within a specified time of sending the cardgeneration request (e.g., within 24 hours of each other).

FIG. 2 shows a logic flow diagram illustrating embodiments of a paymentfile processing (PFP) component for the HTFP. In FIG. 2, a payment filemay be obtained at 201. In one implementation, the payment file mayinclude details regarding one or more payments from a payor to aprovider. For example, the payor may upload the payment file via a HTFPweb portal to a HTFP server. In another example, a HTFP server maydownload the payment file from a secure FTP of the provider.

A determination may be made at 205 whether there remain payments toprocess. In one implementation, the payment file may be parsed (e.g.,using PHP commands) and each of the payments in the payment file may beprocessed. If there remain more payments to process, the next payment toprocess may be selected at 209.

The payment amount associated with the payment may be determined at 213.In one implementation, payment data associated with the selected paymentmay be parsed (e.g., using PHP commands) to determine the paymentamount. For example, the “|” character may be utilized as a fieldseparator to facilitate the parsing. Similarly, provider detailsassociated with the payment may be determined at 217, payor detailsassociated with the payment may be determined at 221, and the TRNassociated with the payment may be determined at 225. In someimplementations, data associated with the payment may be stored via aMySQL database command similar to the following:

INSERT INTO Payments (payment_ID, payment_amount, provider_details,payor_details, TRN)

VALUES (“payment identifier”, “payment amount”, “provider details”,“payor details”, “TRN”);

An ACH request associated with the selected payment may be sent to anissuer bank at 229. For example, the ACH request may be sent via anetwork. In one implementation, parsed data associated with the selectedpayment may be utilized to create the ACH request. For example, thepayment amount may be utilized as the amount of the ACH request. Inanother implementation, additional stored data may be utilized to createthe ACH request. For example, the payor's TIN may be utilized toretrieve the payor's account number at the payor's bank, which may beutilized in the ACH request, via a MySQL database command similar to thefollowing:

SELECT account_number FROM Payors WHERE payor_ID=“payor's TIN”;

A determination may be made at 233 whether payment confirmation shouldbe obtained. For example, the HTFP server (e.g., operated by an issuer)may wish to be notified that the issuer's bank received funds from thepayor's bank to reduce the risk of processing the payment associatedwith non-payment by the payor. In one implementation, this determinationmay be made based on a configuration setting of the HTFP server.

If it is determined that payment confirmation should be obtained, adetermination may be made at 237 whether payment confirmation wasobtained. For example, a determination may be made whether the issuerbank sent a payment confirmation via a network. If it is determined thatpayment confirmation was not obtained, an error notification may begenerated at 241. For example, the error notification may notify a HTFPadministrator that payment confirmation was not obtained.

If it is determined that payment confirmation was obtained or if paymentconfirmation is not desired, a card generation request may be sent to anissuer server at 245. For example, the card generation request may besent via a network. In one implementation, parsed data associated withthe selected payment may be utilized to create the card generationrequest. For example, the provider's name may be utilized in the cardgeneration request. In another implementation, additional stored datamay be utilized to create the card generation request. For example, theprovider's TIN may be utilized to retrieve the provider's address, whichmay be utilized in the card generation request, via a MySQL databasecommand similar to the following:

SELECT address FROM Providers WHERE provider_ID=“provider's TIN”;

The card generation request may instruct the issuer server to generate acard to facilitate the payment.

FIG. 3 shows a logic flow diagram illustrating embodiments of a cardgenerating (CG) component for the HTFP. In FIG. 3, a card generationrequest may be received at 301. For example, an issuer server mayreceive the card generation request from a HTFP server via a network.

A determination may be made at 305 regarding the type of card togenerate. In one implementation, the CG component may generate a singleuse card. In another implementation, the CG component may generate areloadable card. In one implementation, this determination may be madebased on a configuration setting of the issuer server. In anotherimplementation, this determination may be made based on data associatedwith the card generation request. For example, the card generationrequest may be parsed to determine a payor's identifier and/or aprovider's identifier, and preferences of the payor and/or of theprovider may be retrieved from a database to determine the type of cardto generate.

If it is determined that a single use card should be generated, a cardnumber associated with the card may be generated at 311. In oneimplementation, the card number may be generated in accordance withISO/IEC 7812. For example, the card number may be 16 digits in lengthand may include a six-digit Issuer Identification Number (IIN), anine-digit individual account identifier, and a single check digitcalculated using the Luhn formula. A CVV code associated with the cardmay be generated at 313. In one implementation, a random three digitnumber may be generated. An expiration date associated with the card maybe generated at 315. In one implementation, the expiration date may beset in accordance with a specified configuration setting. For example,the expiration date may be set to 60 days from the date of the cardgeneration request. In some implementations, data associated with thecard may be stored via a MySQL database command similar to thefollowing:

INSERT INTO Cards (card_number, CVV_code, expiration_date)

VALUES (“card number”, “CVV code”, “expiration date”);

In some implementations, the card may be configured to be usable with aspecified set of allowed Merchant Category Codes (MCCs) (e.g., MCCsapplicable to the healthcare industry) to minimize the risk of fraud.Accordingly, a transaction involving the card would not be processed ifthe provider's MCC was not on the specified set of allowed MCCs.

If it is determined that a reloadable card should be generated, adetermination may be made at 320 whether a card already exists. In oneimplementation, this determination may be made based on data associatedwith the card generation request. For example, the card generationrequest may be parsed to determine the payor's identifier and/or theprovider's identifier, and a determination may be made based on thepayor's identifier and/or the provider's identifier whether anassociated reloadable card already exists. In one embodiment, the cardmay be configured to facilitate payment refunds by the provider. Forexample, if the provider billed the payor $100 for a procedure, but thepatient paid a $20 co-payment, the provider may have to refund $20 tothe payor. While a single use card may rely on the card number tofacilitate refunds, a reloadable card utilizes additional data toprovide a refund for the correct payment. In one implementation, thereloadable card may associate each payment with a unique combinationthat includes a card number, a CVV code, and an expiration date. In thisimplementation, the card number stays constant, but the CVV code isincremented with each payment (e.g., from 000 to 999). Once CVV codesare used up (e.g., 999 is reached), the expiration date may beincremented and CVV codes may be reused with the new expiration date.

If it is determined that a card does not exist, a card number associatedwith the card may be generated at 321. In one implementation, the cardnumber may be generated in accordance with ISO/IEC 7812. For example,the card number may be 16 digits in length and may include a six-digitIssuer Identification Number (IIN), a nine-digit individual accountidentifier, and a single check digit calculated using the Luhn formula.A CVV code associated with the card may be generated at 323. In oneimplementation, the CVV code may be set to an initial number (e.g.,000). An expiration date associated with the card may be generated at325. In one implementation, the expiration date may be set in accordancewith a specified configuration setting. For example, the expiration datemay be set to 60 days from the date of the card generation request.

If it is determined that a card exists, a determination may be made at331 whether to modify the card's CVV code. In one implementation, if CVVcodes for a given expiration date have not been used up, the CVV codemay be incremented (e.g., by one) at 333. For example, the CVV codeassociated with the card may be updated via a MySQL database commandsimilar to the following:

UPDATE Cards

SET CVV_code=“old CVV code+1”

WHERE card_number=“card number”;

A determination may be made at 335 whether to modify the card'sexpiration date. In one implementation, if CVV codes for a givenexpiration date have been used up, the expiration date may beincremented (e.g., by one day, to be 60 days in the future if thecurrent expiration date is less than 60 days in the future) at 337.

A payment amount may be associated with the card at 341. In oneimplementation, the card generation request may be parsed to determinethe payment amount, and the payment amount may be associated with thecard. For example, the “|” character may be utilized as a fieldseparator to facilitate the parsing. Similarly, provider details may bedetermined and associated with the card at 345, payor details may bedetermined and associated with the card at 349, and a TRN may bedetermined and associated with the card at 353.

A determination may be made whether a physical card is indicated at 357.In one implementation, this determination may be made by default (e.g.,utilize virtual cards). In another implementation, this determinationmay be made based on data associated with the card generation request.For example, the card generation request may be parsed to determine apayor's identifier and/or a provider's identifier, and preferences ofthe payor and/or of the provider may be retrieved from a database todetermine whether to generate a physical card.

If it is determined that a physical card is indicated, a physical cardmay be generated at 361. The physical card may be mailed to the providerat 365.

If it is determined that a physical card is not indicated, a cardpayment processing request may be sent at 371. For example, the cardpayment processing request may be sent via a network. In anotherexample, the card payment processing request may be sent via an API call(e.g., a PHP function call). In one implementation, transaction dataassociated with the card (e.g., card number, card CVV code, cardexpiration data, the payment amount, provider details, payor details,TRN) may be utilized to create the card payment processing request(e.g., the data may be included in the card payment processing request,the data may be referenced such as via a transaction identifier). Thecard payment processing request may instruct the issuer server toprocess a card transaction to facilitate the payment.

FIG. 4 shows a logic flow diagram illustrating embodiments of a cardpayment processing (CPP) component for the HTFP. In FIG. 4, a cardpayment processing request may be received at 401. In oneimplementation, the card payment processing request may be parsed toretrieve transaction data. In another implementation, a transactionidentifier may be parsed from the card payment processing request andtransaction data may be retrieved from a database.

A Level 3 card payment request may be generated at 405. The Level 3 cardpayment request may be pushed (e.g., to initiate a credit card paymenttransaction) by an issuer server to prevent a provider from having tomanually input transaction data into the provider's card terminal (e.g.,credit card machine, virtual credit card terminal) to receive the cardpayment associated with the card payment processing request. The Level 3card payment request may include the TRN associated with the cardpayment to facilitate linking the card payment to the corresponding EOPfile and making the card payment compliant with the ACA. In someimplementations, the provider's issuer and acquirer may be the sameentity, facilitating a lower interchange rate and/or more efficientpayment processing for the provider. For example, due to reduced risk offraud, the issuer and/or the acquirer may avoid having to charge a cardnot present fee for processing a virtual card payment. In anotherexample, due to reduced risk of fraud, restrictions on a maximum paymentamount per transaction may be removed (e.g., instead of processing a$1,000,000 payment as ten transactions due to a $100,000 maximum paymentamount per transaction, the $1,000,000 payment may be processed as onetransaction). In one implementation, transaction data associated withthe card payment processing request may be used to generate the Level 3card payment request, which may include Level 1 and/or Level 2 data,such as issuer data 405 a (e.g., card number, card expiration date, cardCVV code), payment data 405 b (e.g., payment amount, payment date),provider data 405 c (e.g., provider's name, provider's address,provider's TIN), and/or the like, and Level 3 data, such as payor data405 d (e.g., payor's name, payor's address, payor's TIN), TRN associatedwith the card payment 405 e, and/or the like.

A determination may be made at 409 regarding payment request route toutilize to push the Level 3 card payment request. In one embodiment, theLevel 3 card payment request may be pushed via an acquirer. A providerassociated with the card may be determined at 411. For example, thisdetermination may be made based on the provider_TIN field of the Level 3card payment request. The acquirer associated with the provider may bedetermined at 413. For example, the provider's TIN may be utilized toretrieve the address of a card payment processing web page of theprovider's acquirer via a MySQL database command similar to thefollowing:

SELECT acquirer_web_page FROM Providers WHERE provider_ID=“provider'sTIN”;

The Level 3 card payment request may be sent to the acquirer at 415. Forexample, the Level 3 card payment request may be sent via the acquirer'scard payment processing web page.

In another embodiment, the Level 3 card payment request may be pushedvia a virtual terminal. A provider associated with the card may bedetermined at 421. For example, this determination may be made based onthe provider_TIN field of the Level 3 card payment request. Theprovider's virtual terminal information may be retrieved at 423. Forexample, the provider's TIN may be utilized to retrieve the provider'scard terminal identifier, user identifier with the provider's acquirer,password associated with the user identifier, and/or the like. The Level3 card payment request may be sent by emulating the provider's virtualterminal at 425. For example, the Level 3 card payment request may besent via web calls and/or API calls to the provider's acquirer using theprovider's virtual terminal information.

In yet another embodiment, the Level 3 card payment request may bepushed via a payment network. The payment network associated with thecard may be determined at 431. For example, this determination may bemade based on the card_number field (e.g., the card number may be parsedto determine the IIN, which identifies the payment network) of the Level3 card payment request. The Level 3 card payment request may be sent tothe payment network at 425. For example, the Level 3 card paymentrequest may be sent to the payment network via web calls and/or APIcalls specified by a configuration setting of the issuer server for thepayment network.

FIG. 5 shows a logic flow diagram illustrating embodiments of a paymentsettling (PS) component for the HTFP. In FIG. 5, a payment settlingrequest may be received at 501. For example, an acquirer server mayreceive the payment settling request via an API call.

A determination may be made at 505 whether payment confirmation shouldbe obtained. For example, the acquirer server may wish to be notifiedthat the acquirer's bank received funds associated with a card paymentfrom a payment network to reduce the risk of processing the cardpayment. In one implementation, this determination may be made based ona configuration setting of the acquirer server.

If it is determined that payment confirmation should be obtained, adetermination may be made at 509 whether payment confirmation wasobtained. For example, a determination may be made whether the acquirerbank sent a payment confirmation via a network. If it is determined thatpayment confirmation was not obtained, an error notification may begenerated at 513. For example, the error notification may notify anadministrator that payment confirmation was not obtained.

If it is determined that payment confirmation was obtained or if paymentconfirmation is not desired, the payment amount associated with the cardpayment may be determined at 517. In one implementation, detailsregarding the transaction may be determined based on transaction datasent by an issuer server in the card payment request associated with thecard payment. In another implementation, details regarding thetransaction may be determined based on transaction data sent by apayment network in the payment confirmation associated with the cardpayment. For example, transaction data may be parsed (e.g., using an XMLparser) to determine the payment amount Similarly, provider detailsassociated with the card payment may be determined at 521, payor detailsassociated with the card payment may be determined at 525, and the TRNassociated with the card payment may be determined at 529.

The provider's virtual terminal may be updated with details regardingthe card payment at 533. In one implementation, the provider's virtualterminal may show the card payment as having been received and/or mayshow transaction data associated with the card payment. For example, theprovider may utilize the virtual terminal (e.g., a web portal accessedusing a computer connected to a network, a server based applicationaccessed via a client connected to a network) to monitor card payments.

An ACH CCD+ payment request may be sent to the acquirer bank at 537. Forexample, the ACH CCD+ payment request may be sent via a network. In oneimplementation, transaction data associated with the card payment may beutilized to create the ACH CCD+ request. For example, the payment amountmay be utilized as the amount of the ACH CCD+ request. In anotherimplementation, additional stored data may be utilized to create the ACHCCD+ request. For example, the provider's TIN may be utilized toretrieve the provider's account number at the provider's bank, which maybe utilized in the ACH CCD+ request. The ACH CCD+ request may includethe TRN associated with the card payment to facilitate linking the ACHCCD+ payment to the corresponding EOP file and making the ACH CCD+payment compliant with the ACA.

FIG. 6 shows a logic flow diagram illustrating embodiments of an EOPfile delivering (EFD) component for the HTFP. In FIG. 6, EOP data may beobtained at 601. For example, a payor's server may send EOP data to aHTFP server. In one implementation, the EOP data may include EOP filesfor one or more payments from the payor to a provider.

A determination may be made at 605 whether there remain EOP files toprocess. In one implementation, each of the obtained EOP files may beprocessed. If there remain more EOP files to process, the next EOP fileto process may be selected at 609.

Provider details associated with the selected EOP file may be determinedat 613. In one implementation, the EOP file may be parsed to determinethe identifier of the provider associated with the EOP file. In anotherimplementation, other data, such as a TRN associated with EOP file mayalso be determined.

A determination may be made at 617 whether it is time to deliver the EOPfile to the provider. For example, the HTFP server may be configured todeliver the EOP file within a specified time of sending a cardgeneration request for a payment associated with the EOP file (e.g.,within 24 hours of each other). Accordingly, the HTFP server maydetermine whether delivering the EOP file at the current time wouldsatisfy the specified timing configuration. In one implementation, thisdetermination may be made based on the file name (e.g., File_1.835) ofthe EOP file. For example, if the payment file with a corresponding filename (e.g., File_1.Payment) has been processed, it may be time todeliver the EOP file. In another implementation, this determination maybe made based on a TRN associated with EOP file. For example, if thecard generation request associated with the TRN has been sent, it may betime to deliver the EOP file. If it is not yet time to deliver the EOPfile, the HTFP server may wait until it is time to deliver the EOP fileat 621.

If it is time to deliver the EOP file, the provider's deliverypreferences may be determined at 625. In one implementation, theprovider's delivery preferences may be retrieved from a database basedon the provider's identifier via a MySQL database command similar to thefollowing:

SELECT delivery_preferences FROM Providers WHERE provider_ID=“provider'sTIN”;

A determination may be made at 629 regarding delivery preferences of theprovider. In one embodiment, the provider may wish to have the EOP filedelivered via FTP, email, and/or the like message. Accordingly, the EOPfile may be uploaded to the provider's FTP server (e.g., a secure FTPserver), sent to the provider's email address, and/or the like at 631.For example, the login credentials for the provider's FTP server, theprovider's email address, and/or the like may be specified by theprovider's delivery preferences.

In another embodiment, the provider may wish to have the EOP filedelivered to a clearinghouse or a third party vendor (e.g., thatspecializes in gathering EOP data from various sources, aggregating thedata, and submitting the data to the provider in a single daily file).Accordingly, the EOP file may be sent to the provider's clearinghouse orthird party vendor (e.g., uploaded via FTP, sent via email, and/or thelike) at 635. For example, the login credentials for the clearinghouse'sFTP server, the clearinghouse's email address, and/or the like may bespecified by the provider's delivery preferences.

In yet another embodiment, the provider may wish to pick up the EOP fileat a time convenient to the provider. Accordingly, the EOP file may bemade available to the provider via a provider's portal (e.g., via a webportal) at 639. For example, the provider may be informed (e.g., via anemail message) that the EOP file is available for download at theprovider's portal.

FIG. 7 shows a screenshot diagram illustrating embodiments of a paymentfile for the HTFP. In FIG. 7, a portion of an exemplary payment file 700is shown. The payment file shows data associated with an exemplarypayment and may include details such as the payment amount associatedwith the payment 745, the name of the provider associated with thepayment 765, the TIN of the provider 775, and/or the like. For example,the “|” character may be utilized as a field separator to facilitateparsing of the payment file.

FIG. 8 shows a screenshot diagram illustrating embodiments of a cardgeneration request for the HTFP. In FIG. 8, an exemplary card generationrequest 800 is shown. The card generation request shows data associatedwith an exemplary payment and may include details such as the TRNassociated with the payment 815, the payment amount associated with thepayment 845, the name of the provider associated with the payment 865,the TIN of the provider 875, and/or the like. For example, the “|”character may be utilized as a field separator to facilitate parsing ofthe payment file.

FIG. 9 shows a screenshot diagram illustrating embodiments of an ACHCCD+ payment request for the HTFP. In FIG. 9, an exemplary ACH CCD+format 900 is shown in an exemplary ACH CCD+ payment request 905. TheACH CCD+ payment request shows data associated with an exemplary paymentand may include details such as the TRN associated with the payment 925,the payment amount associated with the payment 945, the name of theprovider associated with the payment 965, and/or the like. The TRN mayinclude details such as the payment identifier 930 that may be used tolink the payment to the corresponding EOP file record, the TIN of thepayor associated with the payment 935, and/or the like. For example, the“*” character may be utilized as a TRN field separator and the “\”character may be utilized as a TRN terminator to facilitate parsing ofthe TRN.

FIG. 10 shows a screenshot diagram illustrating embodiments of an EOPfile for the HTFP. In FIG. 10, an exemplary EOP file format (e.g., 835data file format) 1000 is shown. The EOP file format shows that thetransaction detail header 1005 may include the TRN. A portion of anexemplary EOP file record 1010 structured in accordance with the EOPfile format is shown. The EOP file record shows data associated with anexemplary payment and may include details such as the TRN associatedwith the payment 1015, the national payor identifier of the payorassociated with the payment 1020, the payment identifier 1030, the TINof the payor 1035, the payment amount associated with the payment 1045,the name of the payor 1055, the name of the provider associated with thepayment 1065, the TIN of the provider 1075, and/or the like.

FIG. 12 illustrates alternative embodiments associated withunderwriting. At 1, a provider may decide to utilize the HTFP to receivepayments. For example, the provider may make this decision based oninteraction with a provider membership department (e.g., via a website,via a phone call). At 2, the provider may log into a membershipenrollment portal. At 3, the provider may elect a payment method, a datadelivery method, notices, and/or the like. The provider's demographicsmay be pre-populated by the HTFP, and, at 4, correction of demographicsdata may be obtained from the provider (e.g., via the website of themembership enrollment portal) and/or enrollment of the provider may befinalized. At 5, data may be populated into an application and submittedto underwriting (e.g., after obtaining the provider's agreement to aclick-through agreement) via an API. At 6, the acceptance or denial maybe communicated to the provider. At 7, the acceptance or denial may becommunicated to the HTFP. For example, if the provider is accepted, theHTFP may continue setting up the provider for service. In anotherexample, if the provider is denied, the HTFP may prompt the provider tosubmit corrected and/or additional application data. At 8, a pre-note onthe provider's account may be generated (e.g., by the HTFP, by a partnersystem) upon approval of the provider (a Pre-Note is a process of ACHdebiting and crediting a financial account to validate the account mayreceive or send amounts of money) at 9, the HTFP may be set up forservice. In some implementations, at 10, acquirer and/or issuer systemsmay be updated and/or may communicate member virtual terminalinformation so that the issuing processor may emulate a card terminal aspayment is pushed via a payment network gateway.

FIG. 13 illustrates alternative embodiments associated with a reloadablecard. To utilize a reloadable card, each payment must be associated witha variation of the traditional sixteen (fifteen in the case of AMEX)digit card number. In one embodiment, this is accomplished by utilizingthe 16 digit card number, plus the CVV (e.g., three digits except forAMEX which is four digits), plus the expiration date (e.g., month andyear) of the card as the card number. The CVV and/or the expiration datemay be incremented by payment to generate different numbers for eachpayment. For example, the CVV code may be incremented by one every timea payment on that card number is made, and if the CVV code starts at 000and reaches 999, the expiration date may be incremented by one monthand/or year. By varying validation and/or other codes and/or expirationdates, the same card number can be reused for multiple paymenttransactions and thus a reloadable card can be used while still allowingfor accurate tracking of which transaction, payor, health plan, and/orthe like is associated with each payment.

FIG. 14 illustrates alternative embodiments associated with paymentprocessing. At 1, a payment file may be received from a payor (e.g.,health plan payor system server, a client who has payments to make) by aHTFP server (e.g., PPS system server). The PPS may process the paymentfile, and at 2 send an ACH instruction file that includes the debits foreach plan's bank account representing their part of the payment file tothe PPS's issuing bank The PPS's issuing bank may initiate a debit at 3to each plan's bank account and may receive funds at 4. The PPS mayinstruct the issuing processor to initiate creation of a card at 5(e.g., single use virtual card) and to assign the appropriate amount tothe card. At 6, the issuing processor may push payment to the acquiringprocessor for processing using Level 3, which includes the 835 TRN (Asan alternate, at 6-b, the Issuing Processor may send a separate filecontaining the 835 TRN and a key to match the 835 TRN with the paymentin 6). At 7, the acquiring processor will validate pricing with thepayment network (e.g., MasterCard) which may be BSA pricing which evokesa response at 8 (alternately, 6 and/or 6-b may connect to the card brandin the Payment Network and the card brand may return instructions to theAcquiring processor at 8). At 9, the payment network may ACH debit PPS'sissuing bank for settlement funds on behalf of the acquirer and creditthe acquirer bank may be sent via ACH to the PPS acquirer's bank (thisaction may or may not require the debit to be received before the creditis issued). Upon completion of the settlement process in one embodiment,PPS may be the acquirer and may settle the payment to the providermerchant virtual terminal. At 11, the acquiring bank may notify theacquiring processor the ACH debit from the issuing bank is complete andthe acquiring bank is then instructed (at 12) to initiate an ACH creditto the provider merchant account using the CCD+ format (at 13), whichincludes the 835 TRN from the Level 3 data or the alternate method of aseparate file at 6-b).

In some embodiments, doctors and other healthcare providers receivepayments for the healthcare services that they provide from varioussources and through various payment mechanisms. Payments may be receivedfrom insurance companies, patients, and other parties, and third partysystems and services can be involved in the payment process. Forexample, third parties can make payments to the healthcare provider onbehalf an insurance company or patient and keep track of informationabout such payments.

FIG. 15 illustrates alternative embodiments associated with EOP DataDelivery. At 1, EOP data may be delivered to the EOP delivery system toprovide payment advice to the provider about their payments based ontheir delivery preferences. In one embodiment, at 2, 835 data (or someother agreed upon format) may be delivered to the provider by deliveringthe data to the provider's clearinghouse and/or another designated thirdparty. In another embodiment, at 3, 835 data (or some other agreed uponformat) may be delivered to the provider by uploading the data to theprovider's FTP. At 4, 835 data (or some other agreed upon format) may bedelivered to the provider by letting the provider pick up the data(e.g., by logging into a web portal and downloading the data at a timeconvenient to the provider). At 5, an email with a data file (e.g., flatfile, excel file, pdf file) or a fax with an image of the EOP may besent to the appropriate party. In some implementations, instead ofhaving an attached data file, the email may include a secure link into aweb portal that facilitates the download of the data file by theappropriate party (e.g., upon providing a username and password to loginto the web portal).

FIGS. 16-40 illustrate a technique that can be used to make payments tohealthcare providers. In this example a third-party payment service PPSreceives payment data from a payor in step 1, shown in FIG. 16. Forexample, a payer may provide information saying that a doctor D shouldbe paid an amount X for services provided to a patent P.

In step 2, shown in FIG. 17, the third-party payment service PPSinitiates a request for a Bank (e.g. UMB) to debit the plan's account.

In step 3, shown in FIG. 18, a debit is initiated on the plan's account.This sets up a credit that will eventually come back to the third-partyservice PPS. Ideally, the third-party PPS receives the money in-housebefore payment is made to the healthcare provider. These steps areprovided as examples of moving money to facilitate the payment, forexample, via the issuance of a credit card or other instrument.Additional or alternative steps may be involved.

In step 4, shown in FIG. 19, the plan's bank initiates a credit transferto the third party service provider's bank

In step 5, shown in FIG. 20, a credit card payment is initiated. Thismay involve sending a file to an issuer credit card processor, such asStore Financial, and setting up the card so that it can be sent out.

In step 6, shown in FIG. 21, two faxes are sent to the healthcareprovider, one for the payment data and one for the payment. In thisexample, the fax has a single use virtual credit card number that thehealthcare provider can use to receive payment.

In step 7, shown in FIG. 22, the healthcare provider processes thepayment, in this example, by processing the received credit cardinformation using an actual or virtual credit card terminal.

In step 8, shown in FIG. 23, the provider's credit card terminalprocesses the payment via the payment network. For example, the creditcard terminal may connects to a credit card network to connect directlyto MasterCard, Visa or another credit card system.

In addition or as an alternative to using credit cards, push paymenttechniques and other payment techniques may be used.

In step 9, shown in FIG. 24, the transaction completes when the issuercredit card processor such as Store Financial validates the transaction.The transaction can be completed by connecting to Store Financial andhaving Store Financial verify the amount.

In step 10, shown in FIG. 25, the healthcare provider (i.e., theacquirer) debits funds from the issuing bank account and in step 11,shown in FIG. 26, funds are credited to the healthcare provider'saccount. These steps move the money from the third party payment serviceaccount to the healthcare provider account.

In FIG. 27, a third-party payment service (e.g., Pay-Plus) is theacquiring processor gateway and uses the gateway to capture competitorpayments to reduce pricing and earn fees for processing the payments.The healthcare provider may receive payment information from thosecompetitors that are entered into the third-party payment service (e.g.,Pay-Plus) provided credit card machines. At 1, the other B2B competingissuing processor may push payment to the acquiring processor forprocessing using Level 3, which may include the 835 TRN(As an alternate,at 1-b, the Issuing Processor may send a separate file containing the835 TRN and a key to match the 835 TRN with the payment in 1). At 2, theacquiring processor will validate pricing with the payment network(e.g., MasterCard) which may be BSA pricing which evokes a response at3. At 4, the payment network may ACH debit Pay-Plus's issuing bank forsettlement funds on behalf of the acquirer and credit to the acquirerbank may be sent via ACH to the Pay-Plus acquirer's bank At 5, theissuing bank may forward the funds to the payment network (e.g.,MasterCard). Upon completion of the settlement process in oneembodiment, Pay-Plus may be the acquirer and may settle the payment tothe provider merchant virtual terminal. At 6, the acquiring bank maynotify the acquiring processor the ACH debit from the issuing bank iscomplete and the acquiring bank is then instructed at 7 to initiate anACH credit to the provider merchant account using the CCD+ format (at8), which includes the 835 TRN from the Level 3 data.

In some embodiments, a medical service provider may provide services tomultiple patients and accept payments from multiple payors including butnot limited to the patients themselves, insurance companies, self-fundedcorporations, unions, and other third-party payors. An intermediary canact between payors and service providers to reduce the amount of effortrequired by the medical service provider to accept and track paymentsmade by payors for services provided to patients.

An exemplary payment facilitation system may use an intermediary serverwhich acts as an intermediary between one or more payors and one or moreservice providers to provide various functions related to the payment ofa provider for services. Such functions include, but are not limited to,aggregating payments, providing a physical or virtual card preloadedwith funds for payment, pushing the payments to a provider's credit cardmerchant account, transferring the payment to a provider's bank accountand/or tracking information related to the payments. A merchant accountmay be a line of credit account or a bank account with an acquiring bankor financial institution that processes credit and/or debit cardpayments. The intermediary server may be provided by a third party otherthan the payors and service providers. The payors and service providers,for example, may contract with the third party intermediary to performsuch functions. In one embodiment, the system offers different tiers ofmembership where the different tiers receive different services. As aspecific example, the intermediary may process payments on behalf of apayor to both service providers that are members and service providersthat are not members, providing features to members that are notavailable to the non-members.

An exemplary payment facilitation system may include a third partysystem that receives a plurality of payment files, payable to one ormore member and non-member providers of the third party system, from aplurality of payors. The system may determine that one or more of thepayment requests are payable to a member provider. The system may thenrequest and aggregate funds from multiple payors into a single paymentto a member provider. The single payment is made to an accountassociated with the member. If the member provider has chosen to havehis aggregated payment pushed into his merchant account, the payment maybe pushed into his merchant account without requiring that the memberact to receive the payment. To accomplish this, the member provider mayhave provided the third party system with information sufficient toidentify his merchant account. Thus, the member provider would receivethe aggregated payment in his merchant account as a push payment, i.e.,without necessarily having to enter any information into his credit cardmachine, terminal or web based computer program.

In another embodiment the member provider may have chosen to have thesingle aggregated payment transferred from the account associated withthe member provider directly to his bank account using the AutomatedClearing House (ACH), which is an e-payment network which allows fundtransfers to occur using Electronic Funds Transfer (EFT).

The following example is provided to illustrate an exemplary use of asystem in which an intermediary acts to aggregate and/or push paymentsdirectly into a member provider's merchant account or bank account. Inthis example, two payors (P1 and P2) each send requests to theintermediary server requesting payments be made and delivered to each oftwo medical service providers M1 and M2. An exemplary request is anelectronic message or file containing the details of the request.Medical service provider M1 is a member of the third party system andhas set up his account to have his/her aggregated payments pushed to hismerchant account, in doing so M1 has provided the third party systemwith sufficient information to identify his merchant account with amerchant bank, for example the member provider's Merchant ID andTerminal ID. Service provider M2 is also a member of the third partysystem and has set up his account to have his his/her aggregatedpayments deposited directly into his bank account, and has provided thesystem with sufficient information to identify his bank account. Theintermediary server receives P1 and P2's payment requests and determinesthat payments are to be made to both M1 and M2.

The intermediary server requests the funds for M1 from P1 and P2'saccounts and coordinates the transfer of those funds into a bank accountassociated with M1. This account is used by the system for issuingpayments to M1. The intermediary server then instructs the bank serverto push the funds, which amount to the aggregated payment from P1 andP2, from the bank account associated with M1 to a processor for receipt,processing and depositing into M1's merchant bank account. In doing so,the funds appear in M1's merchant account as if M1 accepted a creditcard payment via the member provider's credit card machine or terminalfor the single aggregated payment amount, but without any action beingtaken by M1, i.e., M1 does not have to swipe a credit card through acredit card machine. The push can be facilitated by a transactionprocessor that, for example, also receives requests to make paymentsinto the merchant account via an associated credit card machine orterminal The processor may be a part of a credit card network, it may beassociated with the intermediary server, it may be associated with amerchant bank server, or may otherwise be provided.

Service provider M2, having requested his aggregated payment bedeposited directly into his bank account, will have provided the thirdparty system with information related to his bank account, such as therouting and account numbers for the member provider's account. Theintermediary server requests the funds for M2 from P1 and P2's accountsand transfers those funds into a bank account associated with M2 andused by the system for issuing payments to M2. The intermediary serverthen instructs the bank server to push the funds, which amount to theaggregated payment from P1 and P2, from the bank account associated withM2 directly into M2's bank account, in some cases using ACH. Both M1 andM2 may receive notification of the aggregate payment made and may haveaccess to information related to their respective aggregate payments viaa secure web portal.

Pushing payments into a member provider's merchant account may beaccomplished in various ways. In an exemplary payment facilitationsystem where a member provider chooses to have his/her single aggregatedpayments pushed to his merchant account, he may provide informationsufficient to identify his merchant account including, for example, oneor more of a Merchant ID, Terminal ID, Connection User Name, ConnectionPassword, BIN (Bank Identification Number), Terminal ID, Bank ID, UserName, Password, Check Digit, POSID (Point of Sale ID), AuthenticationCode, Merchant Zip Code, or other information sufficient to identify themember provider's merchant account.

In still yet another embodiment the member may be issued a virtual orphysical card, which may be a reloadable or a one-time use card. Thecard may be associated with an account at a card issuer bank associatedwith the member provider. The member provider may choose to have his/hersingle aggregated payments transferred to the account at the card issuerbank associated with the member provider's card. When swiped in apayment card device, either physically or by manually entering the cardnumbers into the device, the card may move funds from the card issuerbank account associated with the member (and card) to the account towhich the credit card device is linked. When the card is swiped thenumber is entered into the credit card terminal and the payment amountis entered, the terminal requests funds from the card issuer bank serverusing a processor such as the United States credit card associationnetwork. A response, such as an approval, may be transmitted to thecredit card terminal Upon approval, funds may be electronically movedfrom the account associated with the member at the card issuer bank tothe account associated with the credit card terminal as dictated by thebank associated with the card's settlement process. For example, fundspayable to a member provider from various payors may be deposited intoan account associated with the member provider (and card) at the cardissuing bank, and when the card is swiped in the credit card terminal,the funds may be moved from the account at the card issuer bank to themerchant account linked to the credit card terminal. The member providermay receive a notification, such as an e-mail, text message or fax,notifying the member provider that funds are available on the member'scard and the amount of the aggregated payment available.

A reloadable card may be similar to a stored value card in that anamount is deposited for either type of card. A reloadable card maydiffer from a stored value card in that a stored value card may be aone-time use card, for example a gift card. A reloadable card may beused multiple times for multiple transactions. A reloadable card mayhave an expiration date, but like credit cards the card may expire yearsafter the issue date, and may be replaced with a current card prior tothat expiration date. A stored value card may have an expiration datefor the amount loaded on the card, may not be reissued, and may not beloaded with additional funds beyond the initial value. A virtual cardmay comprise a file or notification containing information sufficient toallow the provider to transfer funds from the account associated withthe member provider to the member provider's merchant account, using themember provider's credit card terminal. For example, a virtual card maybe an e-mail or facsimile containing a card number, an expiration dateand a card security code, each of which may be manually entered into themember provider's credit card terminal to transfer funds from theaccount associated with the member provider and the card to the memberprovider's merchant account.

In an embodiment, once a provider becomes a member, information aboutthe provider may be compiled and added to a membership list. A cardassociated with a card issuing bank may be mailed or delivered to themember provider office staff. This delivery may also includeintroductory materials. This card delivery may be initiated by thesystem. The member provider card may be physically sent out by the cardissuing bank The system may direct the card issuing bank regarding whatcards and/or materials to send and when, where, and how to send them. Insome embodiments, the acts of sending out the card and associatedmaterials may be performed by the card issuing bank In otherembodiments, the card issuing bank may outsource the process to acertified fulfillment company. In some other embodiments, no card may beissued, in which case the aggregated payment may be made directlybetween banks through ACH transfers, may be pushed directly into amember provider's merchant account, or otherwise.

In some embodiments, member providers may have a merchant category code(MCC) assigned to their reloadable card which may limit the card's useto certain payment card terminals For example, the MCC code may be afour-digit number assigned to a business by MasterCard, VISA, or someother card provider. In some card networks and systems, all merchantshave an MCC associated with their payment card terminal when thebusiness starts accepting a reloadable card as a form of payment. In thecase of a member provider, the MCC may signify that the MCC assignee isa medical provider. The card may be limited to use with a card terminalhaving a matching MCC assignment and/or to card terminals having codesindicating that they are associated with medical providers.

Non-member providers may not be offered the same options for payment fortheir services. For example, non-member providers may only receivenon-aggregated payments on a payor-by-payor basis via either printedcheck, or one-time use cards. The one-time use card may be either aphysical card or a virtual card and may be pre-loaded with the paymentamount associated with a single payor's payment. A non-member may nothave access to the portal and may not receive a notification that apayment has been loaded onto the one-time use card, other than receiptof the card and instructions for its use.

In an embodiment the intermediary server may also provide a memberprovider with a notification of a payment made via ACH, deposited intothe merchant account, or made available via the virtual or physicalcard. The intermediary server may also provide access to informationrelated to the aggregated payment, for example the payments aggregatedon a payor-by-payor basis, and an explanation of payment (EOP) for eachpayment included in the aggregate payment. This information may beaccessible via a web portal or other network access.

The web portal may provide several functions to users. For example,providers may elect to become members, options may be made available tomembers such as communication options for notification of availablefunds (for example, by text message to a phone. e-mail, or fax), optionson how to receive data detailing payment information (such as EOP data)into member record keeping systems or practice management systems (suchas system A40 shown in FIG. 28) (for example by printing and manualentry, downloading various file types for importing into the practicemanagement system, and/or visually reviewing the EOP data).

Users associated with the member providers may log into the web portaland may view transactions, print them, and/or download them in a filewhich may be imported into the member provider's practice managementsystem. For example, this file may be used to note received payments inpatient accounts. Historical and recent transaction records may bemaintained and made accessible in the web portal. The data downloaded bythe member provider may be transmitted using any technology, for exampleSMTP, SMS, MMS, HTTP, HTTPS, FTP, and/or other formats. In someembodiments the member provider users may download a spreadsheet file, aCSV file, a PDF file, or an 835 file for loading into their practicemanagement system. An 835 is an insurance industry standard X12Transaction Set. The data contents of the health care claimpayment/advice 835 file may be used to make a payment and/or send an EOPremittance advice from a payor to a health care provider either directlyor via a financial institution. The web portal may also allow a user toselect member features, to select how they are notified of fundsavailability, and/or select how they obtain data to load into theirpractice management system and reconcile payments. For example, a day'spayment may be an aggregated amount of $12,000 for ten differentpatients from ten different payor servers. By loading the file intotheir practice management system, a user may be able to electronicallycancel out receivables for the ten patients from the ten different payorservers. The web portal may provide information about membershipbenefits and policies. The web portal may also enable membershipactivation by collecting registration data from providers. Should aprovider decide to become a provider member, they may have the abilityto create a user ID and password within the membership portal, electnotification means for payment notifications (for example, e-mail,dial-up IVR, fax, text message to a mobile device, member log-in), agreeto terms of membership, give notice of payors from which they would liketo receive payment through the system, and/or provide a digitalsignature agreeing to terms of membership.

FIG. 28 depicts an exemplary payment facilitation system. In someembodiments, the system A20 may facilitate payments for medical servicesto medical service providers from entities responsible for paying atleast a portion of those services (“payors”). The system A20 maycomprise one or more computers. A computer may be any programmablemachine capable of performing arithmetic and/or logical operations. Insome embodiments, computers may comprise processors, memories, datastorage devices, and/or other commonly known or novel components. Thesecomponents may be connected physically or through a network or wirelesslinks Computers may also comprise software comprising instructionsperformed by one or more processors that may direct the operations ofthe aforementioned components. Computers may include servers, PCs,mobile devices, and other devices that are capable of performing thedescribed functions.

The computers of the system A20 may include one or more servers A21,webservers A22, and/or FTP servers A27. In some embodiments, variousfunctions associated herein with the system servers A21, web serversA22, and FTP servers A27 may be added, omitted, or modified. In somecases different servers may perform different functions, or functionsmay be shared among servers in different ways without departing from thescope of the specification. A system server A21 may process data sent toor received from a payor server A10, payor's bank server All, cardissuer bank server A30, member provider server A42, and/or any otherserver. The system server A21 may communicate with these servers via aweb server A22, FTP server A27, and/or any other communication channelsor networks which may connect the various servers using traditional ornovel communication lines and protocols. The member provider server A42may be a server, Person Computer (PC), mobile device, or other devicecapable of performing the described functions.

The web server A22 may provide a communications portal which houses thesystem's website, and may handle communication with the Internet A50 insome embodiments. The system's website or web portal, may provide publicand/or private visibility to membership services and information whichmay be associated with the system. Providers may sign up to be membersof the system and in doing so may have increased options and benefitsfor services provided by the system as compared with non-members. Forexample, non-members may not receive single aggregated payments, butinstead may be limited to receiving a payment on a payor-by-payor basisvia a physical or virtual card that must be swiped or manually enteredin their credit card terminal. Member providers, however, may receivesingle aggregated payments from multiple payors that may be pusheddirectly into their merchant accounts without having to swipe a creditcard, or transferred to their bank account via an ACH transfer.

One or more payor servers A10 may be connected to the system A20. Apayor server A10 may be a server operated by a payor, such as aninsurance company, self-funded corporation, third-party administrator,union, or the like. Connections to the payor server A10 may include avariation of file transfer protocol such as FTP or FTPS, Internet A50file transfer, a direct data line connection using commerciallyavailable or propriety data lines and transmission protocols, and/orsecure and non-secure email communication via the Internet A50. The FTPserver A27 may provide FTP and/or FTPS (secure FTP) connectivity betweencomputers in the system A20 and external servers such as the payorserver A10, the payor's bank server All, and/or others. In someembodiments the connection type may be selected by the payor server A10.

One or more of payor's bank servers A11 may be connected to the systemA20. A payor's bank server A11 may be a server operated by a bank atwhich one or more payors has an account. Connections to the payor's bankserver A11 may include FTPS, Internet A50 file transfer, a direct dataline connection using commercially available or proprietary data linesand transmission protocols, and/or secure and non-secure email via theInternet A50. In some embodiments the connection type may be chosen byeither the payor server A10 or the payor's bank server A11. In someembodiments the system A20 may communicate with the payor's bank serverA11 through the payor server A10. This communication option may beprovided instead of, or in addition to, a connection between the systemA20 and the payor's bank server A11. In such an example, the system A20may communicate with the payor's bank server A11 through the payorserver A10 by sending a communication to the payor server A10, which mayreroute the communication using any of the above communication options.

One or more card issuer bank servers A30 may be connected to the systemA20. In another example the card issuer bank may outsource the server'sfunctions to a third party processor. A card issuer bank server A30 maybe a server operated by a bank which may issue real or virtual cardslinked to an account at the card issuer bank The system server A21 mayinstruct the payor's bank server A11 to transfer funds from the payor'saccounts to the card issuing bank server A30. The system server A21 maythen instruct the card issuing bank server A30 to divert the fundsreceived from the payor's bank server A11 into specific accountsassociated with specific member providers A45. The card issuer bankserver A30 may have accounts A45, each associated with individual memberproviders. The system server A21 may instruct the card issuer bankserver A30 to push funds from the member provider's account A45 to aprocessor A60 for authorization and deposit into the member provider'smerchant account A62. The processor A60 may be a credit card processor,a merchant account provider, a credit card network, the system serverA21, a payment gateway or another third party processor. The processorA60 authorizes the transfer of funds and instructions the merchant bankserver A41 to deposit the funds into the member provider's merchantaccount A62. In summary, the funds are transferred from the account A45associated with the member provider into the member provider's merchantaccount A62 as if the payment had been made at the member provider'soffice using the member provider's credit card machine/terminal Thesystem may be notified by the processor A60 that the funds weresuccessfully deposited in the member provider's merchant account A62,the system may send a notification to the member provider in a methodthe member provider has chosen (for example, email A46, fax A44, textA43, or displayed when a user associated with a member provider logsinto the member web portal provided on web server A22). The memberprovider A40 may access the member web portal using member providerpractice management server A42 via the Internet A50.

In other embodiments a bank server accessible to the Automated ClearingHouse Network (ACH) and member bank account server may communicatedirectly using ACH funds transfer systems, as depicted, for example inFIG. 29. As shown in FIG. 29 a system A100, having a system server A112may process data sent to or received from a payor server A116, payor'sbank server A118, ACH bank server A120, member bank account server A122,and/or any other server. The system server A112 may communicate withthese servers via a web server A110, FTP server A114, and/or any othercommunication channels or networks which may connect the various serversusing traditional or novel communication lines and protocols.

The web server A110 may provide a communications portal which houses thesystem's website, and may handle communication with the Internet A102 insome embodiments. The system's website or web portal, may provide publicand/or private visibility to membership services and information whichmay be associated with the system. Providers may sign up to be membersof the system and in doing so may have increased options and benefitsfor services provided by the system as compared with non-members. Forexample, non-members may not receive aggregated payments, but insteadmay be limited to receiving a payment on a payor-by-payor basis via aphysical or virtual card that must be swiped in their credit cardterminal. Member providers, however, may receive an aggregated paymentfrom multiple payors that may be pushed directly into their bank accountvia the ACH.

One or more payor servers A116 may be connected to the system A100. Apayor server A116 may be a server operated by a payor, such as aninsurance company, self-funded corporation, third-party administrator,union, or the like. Connections to the payor server may include avariation of file transfer protocol such as FTP or FTPS, Internet filetransfer, a direct data line connection using commercially available orpropriety data lines and transmission protocols, and/or secure andnon-secure email communication via the Internet A102. The FTP serverA114 may provide FTP and/or FTPS (secure FTP) connectivity betweencomputers in the system A100 and external servers such as the payorserver A116, the payor's bank server A118, the ACH bank server A120,and/or others. In some embodiments the connection type may be selectedby the payor server A116.

In some embodiments the system A100 may communicate with the payor'sbank server A118 through the payor server A116. This communicationoption may be provided instead of, or in addition to, a connectionbetween the system A100 and the payor's bank server A118. In such anexample, the system A100 may communicate with the payor's bank serverA118 through the payor server A116 by sending a communication to thepayor server A116, which may reroute the communication using any of theabove communication options.

One or more ACH bank server(s) A120 may be connected to the system A100,in another example the ACH bank server A120 may outsource the server'sfunctions to a third party processor. An ACH bank server A120 may be aserver operated by a bank The system server A112 may instruct thepayor's bank server A118 to transfer funds from the payor's accounts tothe ACH bank server A120. The system server A112 may then instruct theACH bank server A120 to divert the funds received from the payor's bankserver A118 into specific accounts A124 associated with individualmember providers. The system server A112 may instruct the ACH bankserver A120 to transfer funds from the member provider's account A124 tothe member provider's member bank account server A122, with instructionsto divert funds in the member provider's bank account A126. In summary,the funds are transferred from the account associated with the memberprovider A124 into the member provider's bank account A126. The systemA100 may be notified by the ACH bank server A120 or the member bankaccount server A122 that the funds were successfully deposited in themember provider's account A126. The system A100 may then sendnotification to the member provider by a method the member provider haschosen (for example, email A108, fax A106, text A107, or displayed whena user associated with a member provider logs into the member webportal).

FIG. 30 depicts an exemplary process of obtaining and converting a datafile intended for a printer to produce checks/EOBs and EOPS into anelectronic payment file. The system A301 may provide a fully electronicpayment settlement service to its provider members using variousembodiments of the present invention, including, for example withoutlimitation, a push payment to the provider's merchant account, directtransfers to the provider's bank account using the Automated ClearingHouse (ACH) network, though other suitable means for payment may also beused. Payor servers A300 may send check files directly to the systemrather than to a check rendering vendor. The check file A310 format andany payor administrator's processes may be in any format from the payorserver A300. The system A301 may import the check file A310 and compareproviders' Tax Id Number (TIN), or other identifying information, in thecheck file A310 to a the member provider file A320, which may includeinformation on current member providers such as TIN, to determine whichclaims are for payment to member providers versus non-member providers.If the payment is for a member provider, the check file A310 may beconverted to an electronic payment file. If the member provider TIN isfound in the check file A310, a payment to the member provider may beremoved from the check file A310. The patient's EOB copy may be removedand/or adjusted to reflect electronic payment rather than check paymentA330 and then replaced A340 with an EOB containing electronictransaction details. The remaining check file A350 containing non memberpayments and corrected patient EOB copies may be forward on to a checkrendering vendor server A302 for normal printing and mailing A360. Insome embodiments the updated check file A350 may be sent to the payor,and the payor may send the updated check file A350 to the check printvendor A302.

FIG. 31 depicts a process of enrollment wherein the member providerchooses to have his/her aggregated payments from payors pushed into themember provider's merchant account. The provider begins the enrollmentprocess with the system by entering the enrollment wizard A500. If theconnection type of the credit card processor used by the member providermatters A502 then the member provider selects whether the memberprovider uses a credit card machine A503. If the member does not acceptcredit cards at all, then he is routed to the ACH payment enrollmentsystem. If the member provider uses a credit card machine then he isinstructed to obtain a new Tax ID setup as e-commerce. If the memberprovider does not use a credit card machine then he is directed how tocomplete setup based on whether he uses a website or a computer programto accept credit card payments. If the member provider uses a programwithin the computer then he is instructed to obtain a new Tax ID setupfor e-commerce. If the member provider uses a website, then he continueson in enrollment process to step A505 where he fills out processorspecific fields. For member provider's whose credit card processorsconnection type doesn't matter, the member provider fills out basicrequired fields A501. Where a member provider's processor connectiontype does not matters A504, the member provider fills out processorspecific fields A505. The enrollment wizard then send all the data ithas collected from the member to the credit card processor, which may belocated on the merchant bank's server, via API (application programminginterface) A506. The credit card processor sends the data to a secondtier processor via API at step A507. The credit card processor validatesthe data provided at step A508 and if the boarding is successful at stepA509 then the credit card processor receives the Merchant ID andMerchant Key A514, loads the Merchant ID and Merchant Key into theDatabase A515 and the credit card processor responds to the system'sserver with success A516. If the Boarding was not successful at stepA509, then the credit card processor receives notice of failure A510,the credit card processor responds to the system's server with failureinfo A511, the system's server contacts the member provider to correctthe information provided during enrollment A512 and the member providercorrects the information entered in the enrollment wizard A513 and theenrollment wizard again sends the data to the credit card processor viaAPI at A506 and the process continues as described above.

FIG. 32 depicts a membership recruitment process according to anembodiment of the invention. This process may enable the system A406 torecruit providers A412 who may then receive payments through the systemA406 and/or have access to data and services provided by the systemA406. Profiles of prospective member providers may be created by thesystem A406. Various payor servers A400 may provide data A402 detailinghistorical provider payments which may be imported into the systemserver A407 through the secure FTP server A404 or some other suitablechannel. Other commercially available data may also be included whenconstructing the profile. Data A402 from some or all payor servers A400may be aggregated. This data A402 may include summary data on frequencyof historical payments, amounts of historical payments, and/or otherrelevant information. The data A402 may be used to select providers A412for recruitment A408, and the data A402 may be used in recruitmentmaterials.

Providers A412 who are current members and/or providers A412 who mayhave previously opted not to be member providers may be set aside by thesystem A406. In some embodiments, providers A412 who have opted out maybe periodically selected for recruitment A408 and re-approached. Thesystem A406 may select A408 providers A412 who have a relatively highfrequency of payments over a dollar threshold. The frequency and/ordollar threshold may vary by marketing campaign. In some embodiments,other selection criteria may be used.

Once the providers A412 are selected for marketing A408, they may becontacted via a combination of various methods A410, for example bye-mail, mail via USPS or other carrier, telephone, and/or fax.Information presented in the recruitment process may include an InternetURL for the web portal A418. The web server A420 may also be used torecruit providers A412 using various web marketing techniques such asweb blogs, random e-mail campaigns, search engine advertising, and/orthe like. These web marketing techniques may direct the providers A412to the web portal A418. A provider A412 may access the internetmembership portal A418 to enroll in the system and become a memberprovider using the provider's server A414.

FIG. 33 depicts an exemplary process of reconciling payments to memberproviders. When a period's transactions have been aggregated, a payorserver A602 reconciliation file may be created by the system A600. Theperiod may be determined by the system A600, the payor, or the memberprovider. The reconciliation file may include the various electronicpayments which are associated with checks replaced in a payor checkprint file. This reconciliation file may indicate which checks werereplaced by an electronic payment with a reference to the electronicpayment record. For example, if check number 8000 became an electronicpayment, the file may contain the check number 8000 and the data receiptfor the electronic payment and the corresponding amount paid. Thisreconciliation process may be provided in addition to an electronic filereceived by the payor bank displaying cleared checks. Based on the payorserver A602 set up, the file may be made available to the payor serverA602 through a secure FTP site A604 which may be maintained by the FTPserver A606 and/or on the web portal A614 by webserver A608. The webportal A614 may be the same portal described above with respect to FIGS.28-31, or it may be a separate portal. In some embodiments a secureemail A612 may be sent to the payor server A602 indicating a file isavailable. In other embodiments the system server A310 may perform theactions of the web server A608 as described above.

HTFP Controller

FIG. 11 shows a block diagram illustrating embodiments of a HTFPcontroller. In this embodiment, the HTFP controller 1101 may serve toaggregate, process, store, search, serve, identify, instruct, generate,match, and/or facilitate interactions with a computer through paymentplatforms technologies, and/or other related data.

Typically, users, which may be people and/or other systems, may engageinformation technology systems (e.g., computers) to facilitateinformation processing. In turn, computers employ processors to processinformation; such processors 1103 may be referred to as centralprocessing units (CPU). One form of processor is referred to as amicroprocessor. CPUs use communicative circuits to pass binary encodedsignals acting as instructions to enable various operations. Theseinstructions may be operational and/or data instructions containingand/or referencing other instructions and data in various processoraccessible and operable areas of memory 1129 (e.g., registers, cachememory, random access memory, etc.). Such communicative instructions maybe stored and/or transmitted in batches (e.g., batches of instructions)as programs and/or data components to facilitate desired operations.These stored instruction codes, e.g., programs, may engage the CPUcircuit components and other motherboard and/or system components toperform desired operations. One type of program is a computer operatingsystem, which, may be executed by CPU on a computer; the operatingsystem enables and facilitates users to access and operate computerinformation technology and resources. Some resources that may beemployed in information technology systems include: input and outputmechanisms through which data may pass into and out of a computer;memory storage into which data may be saved; and processors by whichinformation may be processed. These information technology systems maybe used to collect data for later retrieval, analysis, and manipulation,which may be facilitated through a database program. These informationtechnology systems provide interfaces that allow users to access andoperate various system components.

In one embodiment, the HTFP controller 1101 may be connected to and/orcommunicate with entities such as, but not limited to: one or more usersfrom user input devices 1111; peripheral devices 1112; an optionalcryptographic processor device 1128; and/or a communications network1113.

Networks are commonly thought to comprise the interconnection andinteroperation of clients, servers, and intermediary nodes in a graphtopology. It should be noted that the term “server” as used throughoutthis application refers generally to a computer, other device, program,or combination thereof that processes and responds to the requests ofremote users across a communications network. Servers serve theirinformation to requesting “clients.” The term “client” as used hereinrefers generally to a computer, program, other device, user and/orcombination thereof that is capable of processing and making requestsand obtaining and processing any responses from servers across acommunications network. A computer, other device, program, orcombination thereof that facilitates, processes information andrequests, and/or furthers the passage of information from a source userto a destination user is commonly referred to as a “node.” Networks aregenerally thought to facilitate the transfer of information from sourcepoints to destinations. A node specifically tasked with furthering thepassage of information from a source to a destination is commonly calleda “router.” There are many forms of networks such as Local Area Networks(LANs), Pico networks, Wide Area Networks (WANs), Wireless Networks(WLANs), etc. For example, the Internet is generally accepted as beingan interconnection of a multitude of networks whereby remote clients andservers may access and interoperate with one another.

The HTFP controller 1101 may be based on computer systems that maycomprise, but are not limited to, components such as: a computersystemization 1102 connected to memory 1129.

Computer Systemization

A computer systemization 1102 may comprise a clock 1130, centralprocessing unit (“CPU(s)” and/or “processor(s)” (these terms are usedinterchangeable throughout the disclosure unless noted to the contrary))1103, a memory 1129 (e.g., a read only memory (ROM) 1106, a randomaccess memory (RAM) 1105, etc.), and/or an interface bus 1107, and mostfrequently, although not necessarily, are all interconnected and/orcommunicating through a system bus 1104 on one or more (mother)board(s)1102 having conductive and/or otherwise transportive circuit pathwaysthrough which instructions (e.g., binary encoded signals) may travel toeffectuate communications, operations, storage, etc. The computersystemization may be connected to a power source 1186; e.g., optionallythe power source may be internal. Optionally, a cryptographic processor1126 may be connected to the system bus. In another embodiment, thecryptographic processor and/or transceivers (e.g., ICs) 1174 may beconnected as either internal and/or external peripheral devices 1112 viathe interface bus I/O 1108 (not pictured) and/or directly via theinterface bus 1107. In turn, the transceivers may be connected toantenna(s) 1175, thereby effectuating wireless transmission andreception of various communication and/or sensor protocols; for examplethe antenna(s) may connect to various transceiver chipsets (depending ondeployment needs), including: Broadcom BCM4329FKUBG transceiver chip(e.g., providing 802.11n, Bluetooth 2.1+ EDR, FM, etc.); a BroadcomBCM4750I UB8 receiver chip (e.g., GPS); a Broadcom BCM4335 transceiverchip (e.g., providing 2G, 3G, and 4G long-term evolution (LTE) cellularcommunications; 802.11ac, Bluetooth 4.0 low energy (LE) (e.g., beaconfeatures)); an Infineon Technologies X-Gold 618-PMB9800 transceiver chip(e.g., providing 2G/3G HSDPA/HSUPA communications); a MediaTek MT6620transceiver chip (e.g., providing 802.11a/b/g/n, Bluetooth 4.0 LE, FM,global positioning system (GPS) (thereby allowing HTFP controller todetermine its location); a Texas Instruments WiLink WL1283 transceiverchip (e.g., providing 802.11n, Bluetooth 3.0, FM, GPS); and/or the like.The system clock typically has a crystal oscillator and generates a basesignal through the computer systemization's circuit pathways. The clockis typically coupled to the system bus and various clock multipliersthat will increase or decrease the base operating frequency for othercomponents interconnected in the computer systemization. The clock andvarious components in a computer systemization drive signals embodyinginformation throughout the system. Such transmission and reception ofinstructions embodying information throughout a computer systemizationmay be commonly referred to as communications. These communicativeinstructions may further be transmitted, received, and the cause ofreturn and/or reply communications beyond the instant computersystemization to: communications networks, input devices, other computersystemizations, peripheral devices, and/or the like. It should beunderstood that in alternative embodiments, any of the above componentsmay be connected directly to one another, connected to the CPU, and/ororganized in numerous variations employed as exemplified by variouscomputer systems.

The CPU comprises at least one high-speed data processor adequate toexecute program components for executing user and/or system-generatedrequests. The CPU is often packaged in a number of formats varying fromlarge mainframe computers, down to mini computers, servers, desktopcomputers, laptops, netbooks, tablets (e.g., iPads, Android and Windowstablets, etc.), mobile smartphones (e.g., iPhones, Android and Windowsphones, etc.), wearable devise (e.g., watches, glasses, goggles (e.g.,Google Glass), etc.), and/or the like. Often, the processors themselveswill incorporate various specialized processing units, such as, but notlimited to: integrated system (bus) controllers, memory managementcontrol units, floating point units, and even specialized processingsub-units like graphics processing units, digital signal processingunits, and/or the like. Additionally, processors may include internalfast access addressable memory, and be capable of mapping and addressingmemory 1129 beyond the processor itself; internal memory may include,but is not limited to: fast registers, various levels of cache memory(e.g., level 1, 2, 3, etc.), RAM, etc. The processor may access thismemory through the use of a memory address space that is accessible viainstruction address, which the processor can construct and decodeallowing it to access a circuit path to a specific memory address spacehaving a memory state. The CPU may be a microprocessor such as: AMD'sAthlon, Duron and/or Opteron; Apple's A series of processors (e.g., A5,A6, A7, etc.); ARM's application, embedded and secure processors; IBMand/or Motorola's DragonBall and PowerPC; IBM's and Sony's Cellprocessor; Intel's 80X86 series (e.g., 80386, 80486), Pentium, Celeron,Core (2) Duo, i series (e.g., i3, i5, i7, etc.), Itanium, Xeon, and/orXScale; Motorola's 680X0 series (e.g., 68020, 68030, 68040, etc.);and/or the like processor(s). The CPU interacts with memory throughinstruction passing through conductive and/or transportive conduits(e.g., (printed) electronic and/or optic circuits) to execute storedinstructions (i.e., program code) according to conventional dataprocessing techniques. Such instruction passing facilitatescommunication within the HTFP controller and beyond through variousinterfaces. Should processing requirements dictate a greater amountspeed and/or capacity, distributed processors (e.g., Distributed HTFP),mainframe, multi-core, parallel, and/or super-computer architectures maysimilarly be employed. Alternatively, should deployment requirementsdictate greater portability, smaller Personal Digital Assistants (PDAs)may be employed.

Depending on the particular implementation, features of the HTFP may beachieved by implementing a microcontroller such as CAST's R8051XC2microcontroller; Intel's MCS 51 (i.e., 8051 microcontroller); and/or thelike. Also, to implement certain features of the HTFP, some featureimplementations may rely on embedded components, such as:Application-Specific Integrated Circuit (“ASIC”), Digital SignalProcessing (“DSP”), Field Programmable Gate Array (“FPGA”), and/or thelike embedded technology. For example, any of the HTFP componentcollection (distributed or otherwise) and/or features may be implementedvia the microprocessor and/or via embedded components; e.g., via ASIC,coprocessor, DSP, FPGA, and/or the like. Alternately, someimplementations of the HTFP may be implemented with embedded componentsthat are configured and used to achieve a variety of features or signalprocessing.

Depending on the particular implementation, the embedded components mayinclude software solutions, hardware solutions, and/or some combinationof both hardware/software solutions. For example, HTFP featuresdiscussed herein may be achieved through implementing FPGAs, which are asemiconductor devices containing programmable logic components called“logic blocks”, and programmable interconnects, such as the highperformance FPGA Virtex series and/or the low cost Spartan seriesmanufactured by Xilinx. Logic blocks and interconnects can be programmedby the customer or designer, after the FPGA is manufactured, toimplement any of the HTFP features. A hierarchy of programmableinterconnects allow logic blocks to be interconnected as needed by theHTFP system designer/administrator, somewhat like a one-chipprogrammable breadboard. An FPGA's logic blocks can be programmed toperform the operation of basic logic gates such as AND, and XOR, or morecomplex combinational operators such as decoders or mathematicaloperations. In most FPGAs, the logic blocks also include memoryelements, which may be circuit flip-flops or more complete blocks ofmemory. In some circumstances, the HTFP may be developed on regularFPGAs and then migrated into a fixed version that more resembles ASICimplementations. Alternate or coordinating implementations may migrateHTFP controller features to a final ASIC instead of or in addition toFPGAs. Depending on the implementation all of the aforementionedembedded components and microprocessors may be considered the “CPU”and/or “processor” for the HTFP.

Power Source

The power source 1186 may be of any standard form for powering smallelectronic circuit board devices such as the following power cells:alkaline, lithium hydride, lithium ion, lithium polymer, nickel cadmium,solar cells, and/or the like. Other types of AC or DC power sources maybe used as well. In the case of solar cells, in one embodiment, the caseprovides an aperture through which the solar cell may capture photonicenergy. The power cell 1186 is connected to at least one of theinterconnected subsequent components of the HTFP thereby providing anelectric current to all subsequent components. In one example, the powersource 1186 is connected to the system bus component 1104. In analternative embodiment, an outside power source 1186 is provided througha connection across the I/O 1108 interface. For example, a USB and/orIEEE 1394 connection carries both data and power across the connectionand is therefore a suitable source of power.

Interface Adapters

Interface bus(ses) 1107 may accept, connect, and/or communicate to anumber of interface adapters, conventionally although not necessarily inthe form of adapter cards, such as but not limited to: input outputinterfaces (I/O) 1108, storage interfaces 1109, network interfaces 1110,and/or the like. Optionally, cryptographic processor interfaces 1127similarly may be connected to the interface bus. The interface busprovides for the communications of interface adapters with one anotheras well as with other components of the computer systemization.Interface adapters are adapted for a compatible interface bus. Interfaceadapters conventionally connect to the interface bus via a slotarchitecture. Conventional slot architectures may be employed, such as,but not limited to: Accelerated Graphics Port (AGP), Card Bus,(Extended) Industry Standard Architecture ((E)ISA), Micro ChannelArchitecture (MCA), NuBus, Peripheral Component Interconnect (Extended)(PCI(X), PCI Express, Personal Computer Memory Card InternationalAssociation (PCMCIA), and/or the like.

Storage interfaces 1109 may accept, communicate, and/or connect to anumber of storage devices such as, but not limited to: storage devices1114, removable disc devices, and/or the like. Storage interfaces mayemploy connection protocols such as, but not limited to: (Ultra)(Serial) Advanced Technology Attachment (Packet Interface) ((Ultra)(Serial) ATA(PI)), (Enhanced) Integrated Drive Electronics ((E)IDE),Institute of Electrical and Electronics Engineers (IEEE) 1394, fiberchannel, Small Computer Systems Interface (SCSI), Universal Serial Bus(USB), and/or the like.

Network interfaces 1110 may accept, communicate, and/or connect to acommunications network 1113. Through a communications network 1113, theHTFP controller is accessible through remote clients 1133 b (e.g.,computers with web browsers) by users 1133 a. Network interfaces mayemploy connection protocols such as, but not limited to: direct connect,Ethernet (thick, thin, twisted pair 10/100/1000/10000 Base T, and/or thelike), Token Ring, wireless connection such as IEEE 802.11a-x, and/orthe like. Should processing requirements dictate a greater amount speedand/or capacity, distributed network controllers (e.g., DistributedHTFP), architectures may similarly be employed to pool, load balance,and/or otherwise decrease/increase the communicative bandwidth requiredby the HTFP controller. A communications network may be any one and/orthe combination of the following: a direct interconnection; theInternet; Interplanetary Internet (e.g., Coherent File DistributionProtocol (CFDP), Space Communications Protocol Specifications (SCPS),etc.); a Local Area Network (LAN); a Metropolitan Area Network (MAN); anOperating Missions as Nodes on the Internet (OMNI); a secured customconnection; a Wide Area Network (WAN); a wireless network (e.g.,employing protocols such as, but not limited to a cellular, WiFi,Wireless Application Protocol (WAP), I-mode, and/or the like); and/orthe like. A network interface may be regarded as a specialized form ofan input output interface. Further, multiple network interfaces 1110 maybe used to engage with various communications network types 1113. Forexample, multiple network interfaces may be employed to allow for thecommunication over broadcast, multicast, and/or unicast networks.

Input Output interfaces (I/O) 1108 may accept, communicate, and/orconnect to user input devices 1111, peripheral devices 1112,cryptographic processor devices 1128, and/or the like. I/O may employconnection protocols such as, but not limited to: audio: analog,digital, monaural, RCA, stereo, and/or the like; data: Apple Desktop Bus(ADB), IEEE 1394a-b, serial, universal serial bus (USB); infrared;joystick; keyboard; midi; optical; PC AT; PS/2; parallel; radio; touchinterfaces: capacitive, optical, resistive, etc. displays; videointerface: Apple Desktop Connector (ADC), BNC, coaxial, component,composite, digital, Digital Visual Interface (DVI), (mini) display port,high-definition multimedia interface (HDMI), RCA, RF antennae, S-Video,VGA, and/or the like; wireless transceivers: 802.11a/ac/b/g/n/x;Bluetooth; cellular (e.g., code division multiple access (CDMA), highspeed packet access (HSPA(+)), high-speed downlink packet access(HSDPA), global system for mobile communications (GSM), long termevolution (LTE), WiMax, etc.); and/or the like. One typical outputdevice may include a video display, which typically comprises a CathodeRay Tube (CRT) or Liquid Crystal Display (LCD) based monitor with aninterface (e.g., DVI circuitry and cable) that accepts signals from avideo interface, may be used. The video interface composites informationgenerated by a computer systemization and generates video signals basedon the composited information in a video memory frame. Another outputdevice is a television set, which accepts signals from a videointerface. Typically, the video interface provides the composited videoinformation through a video connection interface that accepts a videodisplay interface (e.g., an RCA composite video connector accepting anRCA composite video cable; a DVI connector accepting a DVI displaycable, etc.).

User input devices 1111 often are a type of peripheral device 512 (seebelow) and may include: card readers, dongles, finger print readers,gloves, graphics tablets, joysticks, keyboards, microphones, mouse(mice), remote controls, retina readers, touch screens (e.g.,capacitive, resistive, etc.), trackballs, trackpads, sensors (e.g.,accelerometers, ambient light, GPS, gyroscopes, proximity, etc.),styluses, and/or the like.

Peripheral devices 1112 may be connected and/or communicate to I/Oand/or other facilities of the like such as network interfaces, storageinterfaces, directly to the interface bus, system bus, the CPU, and/orthe like. Peripheral devices may be external, internal and/or part ofthe HTFP controller. Peripheral devices may include: antenna, audiodevices (e.g., line-in, line-out, microphone input, speakers, etc.),cameras (e.g., still, video, webcam, etc.), dongles (e.g., for copyprotection, ensuring secure transactions with a digital signature,and/or the like), external processors (for added capabilities; e.g.,crypto devices 528), force-feedback devices (e.g., vibrating motors),network interfaces, printers, scanners, storage devices, transceivers(e.g., cellular, GPS, etc.), video devices (e.g., goggles, monitors,etc.), video sources, visors, and/or the like. Peripheral devices ofteninclude types of input devices (e.g., cameras).

It should be noted that although user input devices and peripheraldevices may be employed, the HTFP controller may be embodied as anembedded, dedicated, and/or monitor-less (i.e., headless) device,wherein access would be provided over a network interface connection.

Cryptographic units such as, but not limited to, microcontrollers,processors 1126, interfaces 1127, and/or devices 1128 may be attached,and/or communicate with the HTFP controller. A MC68HC16 microcontroller,manufactured by Motorola Inc., may be used for and/or withincryptographic units. The MC68HC16 microcontroller utilizes a 16-bitmultiply-and-accumulate instruction in the 16 MHz configuration andrequires less than one second to perform a 512-bit RSA private keyoperation. Cryptographic units support the authentication ofcommunications from interacting agents, as well as allowing foranonymous transactions. Cryptographic units may also be configured aspart of the CPU. Equivalent microcontrollers and/or processors may alsobe used. Other commercially available specialized cryptographicprocessors include: Broadcom's CryptoNetX and other Security Processors;nCipher's nShield; SafeNet's Luna PCI (e.g., 7100) series; SemaphoreCommunications' 40 MHz Roadrunner 184; Sun's Cryptographic Accelerators(e.g., Accelerator 6000 PCIe Board, Accelerator 500 Daughtercard); ViaNano Processor (e.g., L2100, L2200, U2400) line, which is capable ofperforming 500+ MB/s of cryptographic instructions; VLSI Technology's 33MHz 6868; and/or the like.

Memory

Generally, any mechanization and/or embodiment allowing a processor toaffect the storage and/or retrieval of information is regarded as memory1129. However, memory is a fungible technology and resource, thus, anynumber of memory embodiments may be employed in lieu of or in concertwith one another. It is to be understood that the HTFP controller and/ora computer systemization may employ various forms of memory 1129. Forexample, a computer systemization may be configured wherein theoperation of on-chip CPU memory (e.g., registers), RAM, ROM, and anyother storage devices are provided by a paper punch tape or paper punchcard mechanism; however, such an embodiment would result in an extremelyslow rate of operation. In a typical configuration, memory 1129 willinclude ROM 1106, RAM 1105, and a storage device 1114. A storage device1114 may be any conventional computer system storage. Storage devicesmay include: an array of devices (e.g., Redundant Array of IndependentDisks (RAID)); a drum; a (fixed and/or removable) magnetic disk drive; amagneto-optical drive; an optical drive (i.e., Blueray, CDROM/RAM/Recordable (R)/ReWritable (RW), DVD R/RW, HD DVD R/RW etc.); RAMdrives; solid state memory devices (USB memory, solid state drives(SSD), etc.); other processor-readable storage mediums; and/or otherdevices of the like. Thus, a computer systemization generally requiresand makes use of memory.

Component Collection

The memory 1129 may contain a collection of program and/or databasecomponents and/or data such as, but not limited to: operating systemcomponent(s) 1115 (operating system); information server component(s)1116 (information server); user interface component(s) 1117 (userinterface); Web browser component(s) 1118 (Web browser); database(s)1119; mail server component(s) 1121; mail client component(s) 1122;cryptographic server component(s) 1120 (cryptographic server); the HTFPcomponent(s) 1135; and/or the like (i.e., collectively a componentcollection). These components may be stored and accessed from thestorage devices and/or from storage devices accessible through aninterface bus. Although non-conventional program components such asthose in the component collection, typically, are stored in a localstorage device 1114, they may also be loaded and/or stored in memorysuch as: peripheral devices, RAM, remote storage facilities through acommunications network, ROM, various forms of memory, and/or the like.

Operating System

The operating system component 1115 is an executable program componentfacilitating the operation of the HTFP controller. Typically, theoperating system facilitates access of I/O, network interfaces,peripheral devices, storage devices, and/or the like. The operatingsystem may be a highly fault tolerant, scalable, and secure system suchas: Apple's Macintosh OS X (Server); AT&T Plan 9; Be OS; Google'sChrome; Microsoft's Windows 7/8; Unix and Unix-like system distributions(such as AT&T's UNIX; Berkley Software Distribution (BSD) variationssuch as FreeBSD, NetBSD, OpenBSD, and/or the like; Linux distributionssuch as Red Hat, Ubuntu, and/or the like); and/or the like operatingsystems. However, more limited and/or less secure operating systems alsomay be employed such as Apple Macintosh OS, IBM OS/2, Microsoft DOS,Microsoft Windows 2000/2003/3.1/95/98/CE/Millenium/Mobile/NT/Vista/XP(Server), Palm OS, and/or the like. Additionally, for robust mobiledeployment applications, mobile operating systems may be used, such as:Apple's iOS; China Operating System COS; Google's Android; MicrosoftWindows RT/Phone; Palm's WebOS; Samsung/Intel's Tizen; and/or the like.An operating system may communicate to and/or with other components in acomponent collection, including itself, and/or the like. Mostfrequently, the operating system communicates with other programcomponents, user interfaces, and/or the like. For example, the operatingsystem may contain, communicate, generate, obtain, and/or provideprogram component, system, user, and/or data communications, requests,and/or responses. The operating system, once executed by the CPU, mayenable the interaction with communications networks, data, I/O,peripheral devices, program components, memory, user input devices,and/or the like. The operating system may provide communicationsprotocols that allow the HTFP controller to communicate with otherentities through a communications network 1113. Various communicationprotocols may be used by the HTFP controller as a subcarrier transportmechanism for interaction, such as, but not limited to: multicast,TCP/IP, UDP, unicast, and/or the like.

Information Server

An information server component 1116 is a stored program component thatis executed by a CPU. The information server may be a conventionalInternet information server such as, but not limited to Apache SoftwareFoundation's Apache, Microsoft's Internet Information Server, and/or thelike. The information server may allow for the execution of programcomponents through facilities such as Active Server Page (ASP), ActiveX,(ANSI) (Objective-) C (++), C# and/or .NET, Common Gateway Interface(CGI) scripts, dynamic (D) hypertext markup language (HTML), FLASH,Java, JavaScript, Practical Extraction Report Language (PERL), HypertextPre-Processor (PHP), pipes, Python, wireless application protocol (WAP),WebObjects, and/or the like. The information server may support securecommunications protocols such as, but not limited to, File TransferProtocol (FTP); HyperText Transfer Protocol (HTTP); Secure HypertextTransfer Protocol (HTTPS), Secure Socket Layer (SSL), messagingprotocols (e.g., America Online (AOL) Instant Messenger (AIM),Application Exchange (APEX), ICQ, Internet Relay Chat (IRC), MicrosoftNetwork (MSN) Messenger Service, Presence and Instant Messaging Protocol(PRIM), Internet Engineering Task Force's (IETF's) Session InitiationProtocol (SIP), SIP for Instant Messaging and Presence LeveragingExtensions (SIMPLE), open XML-based Extensible Messaging and PresenceProtocol (XMPP) (i.e., Jabber or Open Mobile Alliance's (OMA's) InstantMessaging and Presence Service (IMPS)), Yahoo! Instant MessengerService, and/or the like. The information server provides results in theform of Web pages to Web browsers, and allows for the manipulatedgeneration of the Web pages through interaction with other programcomponents. After a Domain Name System (DNS) resolution portion of anHTTP request is resolved to a particular information server, theinformation server resolves requests for information at specifiedlocations on the HTFP controller based on the remainder of the HTTPrequest. For example, a request such ashttp://123.124.125.126/myInformation.html might have the IP portion ofthe request “123.124.125.126” resolved by a DNS server to an informationserver at that IP address; that information server might in turn furtherparse the http request for the “/myInformation.html” portion of therequest and resolve it to a location in memory containing theinformation “myInformation.html.” Additionally, other informationserving protocols may be employed across various ports, e.g., FTPcommunications across port 21, and/or the like. An information servermay communicate to and/or with other components in a componentcollection, including itself, and/or facilities of the like. Mostfrequently, the information server communicates with the HTFP database1119, operating systems, other program components, user interfaces, Webbrowsers, and/or the like.

Access to the HTFP database may be achieved through a number of databasebridge mechanisms such as through scripting languages as enumeratedbelow (e.g., CGI) and through inter-application communication channelsas enumerated below (e.g., CORBA, WebObjects, etc.). Any data requeststhrough a Web browser are parsed through the bridge mechanism intoappropriate grammars as required by the HTFP. In one embodiment, theinformation server would provide a Web form accessible by a Web browser.Entries made into supplied fields in the Web form are tagged as havingbeen entered into the particular fields, and parsed as such. The enteredterms are then passed along with the field tags, which act to instructthe parser to generate queries directed to appropriate tables and/orfields. In one embodiment, the parser may generate queries in standardSQL by instantiating a search string with the proper join/selectcommands based on the tagged text entries, wherein the resulting commandis provided over the bridge mechanism to the HTFP as a query. Upongenerating query results from the query, the results are passed over thebridge mechanism, and may be parsed for formatting and generation of anew results Web page by the bridge mechanism. Such a new results Webpage is then provided to the information server, which may supply it tothe requesting Web browser.

Also, an information server may contain, communicate, generate, obtain,and/or provide program component, system, user, and/or datacommunications, requests, and/or responses.

User Interface

Computer interfaces in some respects are similar to automobile operationinterfaces. Automobile operation interface elements such as steeringwheels, gearshifts, and speedometers facilitate the access, operation,and display of automobile resources, and status. Computer interactioninterface elements such as check boxes, cursors, menus, scrollers, andwindows (collectively and commonly referred to as widgets) similarlyfacilitate the access, capabilities, operation, and display of data andcomputer hardware and operating system resources, and status. Operationinterfaces are commonly called user interfaces. Graphical userinterfaces (GUIs) such as the Apple's iOS, Macintosh Operating System'sAqua; IBM's OS/2; Google's Chrome; Microsoft's Windows varied UIs2000/2003/3.1/95/98/CE/Millenium/Mobile/NT/Vista/XP (Server) (i.e.,Aero, Surface, etc.); Unix's X-Windows (e.g., which may includeadditional Unix graphic interface libraries and layers such as K DesktopEnvironment (KDE), mythTV and GNU Network Object Model Environment(GNOME)), web interface libraries (e.g., ActiveX, AJAX, (D)HTML, FLASH,Java, JavaScript, etc. interface libraries such as, but not limited to,Dojo, jQuery(UI), MooTools, Prototype, script.aculo.us, SWFObject,Yahoo! User Interface, any of which may be used and) provide a baselineand means of accessing and displaying information graphically to users.

A user interface component 1117 is a stored program component that isexecuted by a CPU. The user interface may be a conventional graphic userinterface as provided by, with, and/or atop operating systems and/oroperating environments such as already discussed. The user interface mayallow for the display, execution, interaction, manipulation, and/oroperation of program components and/or system facilities through textualand/or graphical facilities. The user interface provides a facilitythrough which users may affect, interact, and/or operate a computersystem. A user interface may communicate to and/or with other componentsin a component collection, including itself, and/or facilities of thelike. Most frequently, the user interface communicates with operatingsystems, other program components, and/or the like. The user interfacemay contain, communicate, generate, obtain, and/or provide programcomponent, system, user, and/or data communications, requests, and/orresponses.

Web Browser

A Web browser component 1118 is a stored program component that isexecuted by a CPU. The Web browser may be a conventional hypertextviewing application such as Apple's (mobile) Safari, Google's Chrome,Microsoft Internet Explorer, Mozilla's Firefox, Netscape Navigator,and/or the like. Secure Web browsing may be supplied with 128 bit (orgreater) encryption by way of HTTPS, SSL, and/or the like. Web browsersallowing for the execution of program components through facilities suchas ActiveX, AJAX, (D)HTML, FLASH, Java, JavaScript, web browser plug-inAPIs (e.g., FireFox, Safari Plug-in, and/or the like APIs), and/or thelike. Web browsers and like information access tools may be integratedinto PDAs, cellular telephones, and/or other mobile devices. A Webbrowser may communicate to and/or with other components in a componentcollection, including itself, and/or facilities of the like. Mostfrequently, the Web browser communicates with information servers,operating systems, integrated program components (e.g., plug-ins),and/or the like; e.g., it may contain, communicate, generate, obtain,and/or provide program component, system, user, and/or datacommunications, requests, and/or responses. Also, in place of a Webbrowser and information server, a combined application may be developedto perform similar operations of both. The combined application wouldsimilarly affect the obtaining and the provision of information tousers, user agents, and/or the like from the HTFP enabled nodes. Thecombined application may be nugatory on systems employing standard Webbrowsers.

Mail Server

A mail server component 1121 is a stored program component that isexecuted by a CPU 1103. The mail server may be a conventional Internetmail server such as, but not limited to: dovecot, Courier IMAP, CyrusIMAP, Maildir, Microsoft Exchange, sendmail, and/or the like. The mailserver may allow for the execution of program components throughfacilities such as ASP, ActiveX, (ANSI) (Objective-) C (++), C# and/or.NET, CGI scripts, Java, JavaScript, PERL, PHP, pipes, Python,WebObjects, and/or the like. The mail server may support communicationsprotocols such as, but not limited to: Internet message access protocol(IMAP), Messaging Application Programming Interface (MAPI)/MicrosoftExchange, post office protocol (POP3), simple mail transfer protocol(SMTP), and/or the like. The mail server can route, forward, and processincoming and outgoing mail messages that have been sent, relayed and/orotherwise traversing through and/or to the HTFP.

Access to the HTFP mail may be achieved through a number of APIs offeredby the individual Web server components and/or the operating system.

Also, a mail server may contain, communicate, generate, obtain, and/orprovide program component, system, user, and/or data communications,requests, information, and/or responses.

Mail Client

A mail client component 1122 is a stored program component that isexecuted by a CPU 1103. The mail client may be a conventional mailviewing application such as Apple Mail, Microsoft Entourage, MicrosoftOutlook, Microsoft Outlook Express, Mozilla, Thunderbird, and/or thelike. Mail clients may support a number of transfer protocols, such as:IMAP, Microsoft Exchange, POP3, SMTP, and/or the like. A mail client maycommunicate to and/or with other components in a component collection,including itself, and/or facilities of the like. Most frequently, themail client communicates with mail servers, operating systems, othermail clients, and/or the like; e.g., it may contain, communicate,generate, obtain, and/or provide program component, system, user, and/ordata communications, requests, information, and/or responses. Generally,the mail client provides a facility to compose and transmit electronicmail messages.

Cryptographic Server

A cryptographic server component 1120 is a stored program component thatis executed by a CPU 1103, cryptographic processor 1126, cryptographicprocessor interface 1127, cryptographic processor device 1128, and/orthe like. Cryptographic processor interfaces will allow for expeditionof encryption and/or decryption requests by the cryptographic component;however, the cryptographic component, alternatively, may run on aconventional CPU. The cryptographic component allows for the encryptionand/or decryption of provided data. The cryptographic component allowsfor both symmetric and asymmetric (e.g., Pretty Good Protection (PGP))encryption and/or decryption. The cryptographic component may employcryptographic techniques such as, but not limited to: digitalcertificates (e.g., X.509 authentication framework), digital signatures,dual signatures, enveloping, password access protection, public keymanagement, and/or the like. The cryptographic component will facilitatenumerous (encryption and/or decryption) security protocols such as, butnot limited to: checksum, Data Encryption Standard (DES), EllipticalCurve Encryption (ECC), International Data Encryption Algorithm (IDEA),Message Digest 5 (MD5, which is a one way hash operation), passwords,Rivest Cipher (RC5), Rijndael, RSA (which is an Internet encryption andauthentication system that uses an algorithm developed in 1977 by RonRivest, Adi Shamir, and Leonard Adleman), Secure Hash Algorithm (SHA),Secure Socket Layer (SSL), Secure Hypertext Transfer Protocol (HTTPS),and/or the like. Employing such encryption security protocols, the HTFPmay encrypt all incoming and/or outgoing communications and may serve asnode within a virtual private network (VPN) with a wider communicationsnetwork. The cryptographic component facilitates the process of“security authorization” whereby access to a resource is inhibited by asecurity protocol wherein the cryptographic component effects authorizedaccess to the secured resource. In addition, the cryptographic componentmay provide unique identifiers of content, e.g., employing and MD5 hashto obtain a unique signature for an digital audio file. A cryptographiccomponent may communicate to and/or with other components in a componentcollection, including itself, and/or facilities of the like. Thecryptographic component supports encryption schemes allowing for thesecure transmission of information across a communications network toenable the HTFP component to engage in secure transactions if sodesired. The cryptographic component facilitates the secure accessing ofresources on the HTFP and facilitates the access of secured resources onremote systems; i.e., it may act as a client and/or server of securedresources. Most frequently, the cryptographic component communicateswith information servers, operating systems, other program components,and/or the like. The cryptographic component may contain, communicate,generate, obtain, and/or provide program component, system, user, and/ordata communications, requests, and/or responses.

The HTFP Database

The HTFP database component 1119 may be embodied in a database and itsstored data. The database is a stored program component, which isexecuted by the CPU; the stored program component portion configuringthe CPU to process the stored data. The database may be a conventional,fault tolerant, relational, scalable, secure database such as Oracle orSybase. Relational databases are an extension of a flat file. Relationaldatabases consist of a series of related tables. The tables areinterconnected via a key field. Use of the key field allows thecombination of the tables by indexing against the key field; i.e., thekey fields act as dimensional pivot points for combining informationfrom various tables. Relationships generally identify links maintainedbetween tables by matching primary keys. Primary keys represent fieldsthat uniquely identify the rows of a table in a relational database.More precisely, they uniquely identify rows of a table on the “one” sideof a one-to-many relationship.

Alternatively, the HTFP database may be implemented using variousstandard data-structures, such as an array, hash, (linked) list, struct,structured text file (e.g., XML), table, and/or the like. Suchdata-structures may be stored in memory and/or in (structured) files. Inanother alternative, an object-oriented database may be used, such asFrontier, ObjectStore, Poet, Zope, and/or the like. Object databases caninclude a number of object collections that are grouped and/or linkedtogether by common attributes; they may be related to other objectcollections by some common attributes. Object-oriented databases performsimilarly to relational databases with the exception that objects arenot just pieces of data but may have other types of capabilitiesencapsulated within a given object. If the HTFP database is implementedas a data-structure, the use of the HTFP database 1119 may be integratedinto another component such as the HTFP component 1135. Also, thedatabase may be implemented as a mix of data structures, objects, andrelational structures. Databases may be consolidated and/or distributedin countless variations through standard data processing techniques.Portions of databases, e.g., tables, may be exported and/or imported andthus decentralized and/or integrated.

In one embodiment, the database component 1119 includes several tables1119 a-h:

An accounts table 1119 a includes fields such as, but not limited to: anaccountID, accountOwnerID, accountContactID, assetIDs, deviceIDs,paymentIDs, transactionIDs, userIDs, accountType (e.g., agent, entity(e.g., corporate, non-profit, partnership, etc.), individual, etc.),accountCreationDate, accountUpdateDate, accountName, accountAddress,accountState, accountZIPcode, accountCountry, accoun tEmail,accountPhone, accountAuthKey, accountIPaddress, accountURLAccesCode,accountPortNo, accountAuthorizationcode, accountAcces sPrivileges,accountPreferences, accountRestrictions, and/or the like;

A users table 1119 b includes fields such as, but not limited to: auserID, userSSN, taxID, userContactID, accountID, assetIDs, deviceIDs,paymentIDs, transactionIDs, userType (e.g., agent, entity (e.g.,corporate, non-profit, partnership, etc.), individual, etc.),namePrefix, firstName, middleName, lastName, nameSuffix, DateOfBirth,userAge, userName, userEmail, userSocialAccountID, contactType,contactRelationship, userPhone, userAddress, userCity, userState,userZlPCode, userCountry, userAuthorizationCode, userAccessPrivilges,userPreferences, userRestrictions, and/or the like (the user table maysupport and/or track multiple entity accounts on a HTFP);

A devices table 1119c includes fields such as, but not limited to:deviceID, accountID, assetIDs, paymentIDs, deviceType, deviceName,deviceModel, deviceVersion, deviceSerialNo, devicelPaddress,deviceMACaddress, device_ECID, deviceUUID, deviceLocation,deviceCertificate, deviceOS, appIDs, deviceResources, deviceVersion,authKey, deviceSecureKey, walletAppinstalledFlag,deviceAccessPrivileges, device Preferences, deviceRestrictions, and/orthe like;

A payments table 1119 d includes fields such as, but not limited to:payment_ID, payment_amount, provider_details, payor_details, TRN,accountID, userID, paymentType, paymentAccountNo, paymentAccountName,paymentAccountAu thorizationCodes, paymentExpirationDate,paymentRoutingNo, paymentRoutingType, paymentAddres s, paymentState,paymentZIPcode, paymentCountry, paymentEmail, paymentAuthKey,paymentIPaddress, paymentURLaccessCode, paymentPortNo,paymentAccessPrivileges, paymentPreferences, payementRestrictions,and/or the like;

A providers table 1119 e includes fields such as, but not limited to:provider_ID, provider_name, provider_phone, provider_address,provider_city, provider_state, provider_ZIPCode, provider_country,provider_bank_routing_number, provider_bank_account_number,provider_payments, delivery_preferences, provider_MID,provider_interchange_rate, acquirer_web_page,provider_virtual_terminal_ID, provider_virtual_terminal_password, and/orthe like;

A payors table 1119 f includes fields such as, but not limited to:payor_ID, payor_name, payor_phone, payor_address, payor_city,payor_state, payor_ZIPCode, payor_country, payor_bank_routing_number,payor_bank_account_number, payor_payments, delivery_preferences,payor_MID, payor_interchange_rate, and/or the like;

A cards table 1119g includes fields such as, but not limited to:card_ID, card_number, card_amount, CVV_code, payment_date, expirationdate, valid_MCCs, card_payment_network, card_interchange_rate, TRN,provider_ID, payor_ID, payment_ID, and/or the like;

An EOP table 1119 h includes fields such as, but not limited to:EOP_FileID, TRN, payment_amount, claim_number, date_of service,patient_identifier, amount_billed, discount_amount, deductible_amount,coinsurance_amount, all owed_payment_amount, reason_codes,delivery_preferences, provider_ID, payor_ID, payment_ID, and/or thelike.

In one embodiment, the HTFP database may interact with other databasesystems. For example, employing a distributed database system, queriesand data access by search HTFP component may treat the combination ofthe HTFP database, an integrated data security layer database as asingle database entity.

In one embodiment, user programs may contain various user interfaceprimitives, which may serve to update the HTFP. Also, various accountsmay require custom database tables depending upon the environments andthe types of clients the HTFP may need to serve. It should be noted thatany unique fields may be designated as a key field throughout. In analternative embodiment, these tables have been decentralized into theirown databases and their respective database controllers (i.e.,individual database controllers for each of the above tables). Employingstandard data processing techniques, one may further distribute thedatabases over several computer systemizations and/or storage devices.Similarly, configurations of the decentralized database controllers maybe varied by consolidating and/or distributing the various databasecomponents 1119 a -h. The HTFP may be configured to keep track ofvarious settings, inputs, and parameters via database controllers.

The HTFP database may communicate to and/or with other components in acomponent collection, including itself, and/or facilities of the like.Most frequently, the HTFP database communicates with the HTFP component,other program components, and/or the like. The database may contain,retain, and provide information regarding other nodes and data.

The HTFPs

The HTFP component 1135 is a stored program component that is executedby a CPU. In one embodiment, the HTFP component incorporates any and/orall combinations of the aspects of the HTFP that was discussed in theprevious figures. As such, the HTFP affects accessing, obtaining and theprovision of information, services, transactions, and/or the like acrossvarious communications networks. The features and embodiments of theHTFP discussed herein increase network efficiency by reducing datatransfer requirements the use of more efficient data structures andmechanisms for their transfer and storage. As a consequence, more datamay be transferred in less time, and latencies with regard totransactions, are also reduced. In many cases, such reduction instorage, transfer time, bandwidth requirements, latencies, etc., willreduce the capacity and structural infrastructure requirements tosupport the HTFP's features and facilities, and in many cases reduce thecosts, energy consumption/requirements, and extend the life of HTFP'sunderlying infrastructure; this has the added benefit of making the HTFPmore reliable Similarly, many of the features and mechanisms aredesigned to be easier for users to use and access, thereby broadeningthe audience that may enjoy/employ and exploit the feature sets of theHTFP; such ease of use also helps to increase the reliability of theHTFP. In addition, the feature sets include heightened security as notedvia the Cryptographic components 1120, 1126, 1128 and throughout, makingaccess to the features and data more reliable and secure

The HTFP transforms payment file and EOP data inputs, via HTFPcomponents (e.g., PFP, CG, CPP, PS, EFD), into ACH request, cardgeneration request, card payment request, ACH CCD+ request, and EOP fileoutputs.

The HTFP component enabling access of information between nodes may bedeveloped by employing standard development tools and languages such as,but not limited to: Apache components, Assembly, ActiveX, binaryexecutables, (ANSI) (Objective-) C (++), C# and/or .NET, databaseadapters, CGI scripts, Java, JavaScript, mapping tools, procedural andobject oriented development tools, PERL, PHP, Python, shell scripts, SQLcommands, web application server extensions, web developmentenvironments and libraries (e.g., Microsoft's ActiveX; Adobe AIR, FLEX &FLASH; AJAX; (D)HTML; Dojo, Java; JavaScript; jQuery(UI); MooTools;Prototype; script.aculo.us; Simple Object Access Protocol (SOAP);SWFObject; Yahoo! User Interface; and/or the like), WebObjects, and/orthe like. In one embodiment, the HTFP server employs a cryptographicserver to encrypt and decrypt communications. The HTFP component maycommunicate to and/or with other components in a component collection,including itself, and/or facilities of the like. Most frequently, theHTFP component communicates with the HTFP database, operating systems,other program components, and/or the like. The HTFP may contain,communicate, generate, obtain, and/or provide program component, system,user, and/or data communications, requests, and/or responses.

Distributed HTFPs

The structure and/or operation of any of the HTFP node controllercomponents may be combined, consolidated, and/or distributed in anynumber of ways to facilitate development and/or deployment Similarly,the component collection may be combined in any number of ways tofacilitate deployment and/or development. To accomplish this, one mayintegrate the components into a common code base or in a facility thatcan dynamically load the components on demand in an integrated fashion.

The component collection may be consolidated and/or distributed incountless variations through standard data processing and/or developmenttechniques. Multiple instances of any one of the program components inthe program component collection may be instantiated on a single node,and/or across numerous nodes to improve performance throughload-balancing and/or data-processing techniques. Furthermore, singleinstances may also be distributed across multiple controllers and/orstorage devices; e.g., databases. All program component instances andcontrollers working in concert may do so through standard dataprocessing communication techniques.

The configuration of the HTFP controller will depend on the context ofsystem deployment. Factors such as, but not limited to, the budget,capacity, location, and/or use of the underlying hardware resources mayaffect deployment requirements and configuration. Regardless of if theconfiguration results in more consolidated and/or integrated programcomponents, results in a more distributed series of program components,and/or results in some combination between a consolidated anddistributed configuration, data may be communicated, obtained, and/orprovided. Instances of components consolidated into a common code basefrom the program component collection may communicate, obtain, and/orprovide data. This may be accomplished through intra-application dataprocessing communication techniques such as, but not limited to: datareferencing (e.g., pointers), internal messaging, object instancevariable communication, shared memory space, variable passing, and/orthe like.

If component collection components are discrete, separate, and/orexternal to one another, then communicating, obtaining, and/or providingdata with and/or to other component components may be accomplishedthrough inter-application data processing communication techniques suchas, but not limited to: Application Program Interfaces (API) informationpassage; (distributed) Component Object Model ((D)COM), (Distributed)Object Linking and Embedding ((D)OLE), and/or the like), Common ObjectRequest Broker Architecture (CORBA), Jini local and remote applicationprogram interfaces, JavaScript Object Notation (JSON), Remote MethodInvocation (RMI), SOAP, process pipes, shared files, and/or the like.Messages sent between discrete component components forinter-application communication or within memory spaces of a singularcomponent for intra-application communication may be facilitated throughthe creation and parsing of a grammar. A grammar may be developed byusing development tools such as lex, yacc, XML, and/or the like, whichallow for grammar generation and parsing capabilities, which in turn mayform the basis of communication messages within and between components.

For example, a grammar may be arranged to recognize the tokens of anHTTP post command, e.g.:

w3c—post http://. . . Valuel

where Valuel is discerned as being a parameter because “http://” is partof the grammar syntax, and what follows is considered part of the postvalue Similarly, with such a grammar, a variable “Value1” may beinserted into an “http://” post command and then sent. The grammarsyntax itself may be presented as structured data that is interpretedand/or otherwise used to generate the parsing mechanism (e.g., a syntaxdescription text file as processed by lex, yacc, etc.). Also, once theparsing mechanism is generated and/or instantiated, it itself mayprocess and/or parse structured data such as, but not limited to:character (e.g., tab) delineated text, HTML, structured text streams,XML, and/or the like structured data. In another embodiment,inter-application data processing protocols themselves may haveintegrated and/or readily available parsers (e.g., JSON, SOAP, and/orlike parsers) that may be employed to parse (e.g., communications) data.Further, the parsing grammar may be used beyond message parsing, but mayalso be used to parse: databases, data collections, data stores,structured data, and/or the like. Again, the desired configuration willdepend upon the context, environment, and requirements of systemdeployment.

For example, in some implementations, the HTFP controller may beexecuting a PHP script implementing a Secure Sockets Layer (“SSL”)socket server via the information server, which listens to incomingcommunications on a server port to which a client may send data, e.g.,data encoded in JSON format. Upon identifying an incoming communication,the PHP script may read the incoming message from the client device,parse the received JSON-encoded text data to extract information fromthe JSON-encoded text data into PHP script variables, and store the data(e.g., client identifying information, etc.) and/or extractedinformation in a relational database accessible using the StructuredQuery Language (“SQL”). An exemplary listing, written substantially inthe form of PHP/SQL commands, to accept JSON-encoded input data from aclient device via a SSL connection, parse the data to extract variables,and store the data to a database, is provided below:

<?PHP header( ‘Content-Type: text/plain’); // set ip address and port tolisten to for incoming data $address = ‘192.168.0.100’; $port = 255; //create a server-side SSL socket, listen for/accept incomingcommunication $sock = socket_create(AF_INET, SOCK_STREAM, 0);socket_bind($sock, $address, $port) or die(‘Could not bind to address’);socket_listen($sock); $client = socket_accept($sock); // read input datafrom client device in 1024 byte blocks until end of message do {  $input= “”;  $input = socket_read($client, 1024);  $data .= $input; }while($input // parse data to extract variables $obj =json_decode($data, true); // store input data in a databasemysql_connect(“201.408.185.132”,$DBserver,$password); // access databaseserver mysql_select(“CLIENT_DB.SQL”); // select database to appendmysql_query(“INSERT INTO UserTable (transmission) VALUES ($data)”); //add data to UserTable table in a CLIENT databasemysql_close(“CLIENT_DB.SQL”); // close connection to database ?>

Also, the following resources may be used to provide example embodimentsregarding SOAP parser implementation:

http://www.xav. com/perl/site/lib/SOAP/Parser. html

http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/com.ibm

. IBMDI. doc/referenceguide295. htm

and other parser implementations:

http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/com.ibm.IBMDI.doc/referenceguide259.htm

all of which are hereby expressly incorporated by reference.

In order to address various issues and advance the art, the entirety ofthis application for Healthcare Transaction Facilitation PlatformApparatuses, Methods and Systems (including the Cover Page, Title,Headings, Field, Background, Summary, Brief Description of the Drawings,Detailed Description, Claims, Abstract, Figures, Appendices, andotherwise) shows, by way of illustration, various embodiments in whichthe claimed innovations may be practiced. The advantages and features ofthe application are of a representative sample of embodiments only, andare not exhaustive and/or exclusive. They are presented only to assistin understanding and teach the claimed principles. It should beunderstood that they are not representative of all claimed innovations.As such, certain aspects of the disclosure have not been discussedherein. That alternate embodiments may not have been presented for aspecific portion of the innovations or that further undescribedalternate embodiments may be available for a portion is not to beconsidered a disclaimer of those alternate embodiments. It will beappreciated that many of those undescribed embodiments incorporate thesame principles of the innovations and others are equivalent. Thus, itis to be understood that other embodiments may be utilized andfunctional, logical, operational, organizational, structural and/ortopological modifications may be made without departing from the scopeand/or spirit of the disclosure. As such, all examples and/orembodiments are deemed to be non-limiting throughout this disclosure.Also, no inference should be drawn regarding those embodiments discussedherein relative to those not discussed herein other than it is as suchfor purposes of reducing space and repetition. For instance, it is to beunderstood that the logical and/or topological structure of anycombination of any program components (a component collection), othercomponents, data flow order, logic flow order, and/or any presentfeature sets as described in the FIGS. and/or throughout are not limitedto a fixed operating order and/or arrangement, but rather, any disclosedorder is exemplary and all equivalents, regardless of order, arecontemplated by the disclosure Similarly, descriptions of embodimentsdisclosed throughout this disclosure, any reference to direction ororientation is merely intended for convenience of description and is notintended in any way to limit the scope of described embodiments.Relative terms such as “lower,” “upper,” “horizontal,” “vertical,”“above,” “below,” “up,” “down,” “top” and “bottom” as well as derivativethereof (e.g., “horizontally,” “downwardly,” “upwardly,” etc.) shouldnot be construed to limit embodiments, and instead, again, are offeredfor convenience of description of orientation. These relativedescriptors are for convenience of description only and do not requirethat any embodiments be constructed or operated in a particularorientation unless explicitly indicated as such. Terms such as“attached,” “affixed,” “connected,” “coupled,” “interconnected,” andsimilar may refer to a relationship wherein structures are secured orattached to one another either directly or indirectly throughintervening structures, as well as both movable or rigid attachments orrelationships, unless expressly described otherwise. Furthermore, it isto be understood that such features are not limited to serial execution,but rather, any number of threads, processes, services, servers, and/orthe like that may execute asynchronously, concurrently, in parallel,simultaneously, synchronously, and/or the like are contemplated by thedisclosure. As such, some of these features may be mutuallycontradictory, in that they cannot be simultaneously present in a singleembodiment. Similarly, some features are applicable to one aspect of theinnovations, and inapplicable to others. In addition, the disclosureincludes other innovations not presently claimed. Applicant reserves allrights in those presently unclaimed innovations including the right toclaim such innovations, file additional applications, continuations,continuations in part, divisions, and/or the like thereof. As such, itshould be understood that advantages, embodiments, examples, functional,features, logical, operational, organizational, structural, topological,and/or other aspects of the disclosure are not to be consideredlimitations on the disclosure as defined by the claims or limitations onequivalents to the claims. It is to be understood that, depending on theparticular needs and/or characteristics of a HTFP individual and/orenterprise user, database configuration and/or relational model, datatype, data transmission and/or network framework, syntax structure,and/or the like, various embodiments of the HTFP, may be implementedthat enable a great deal of flexibility and customization. For example,aspects of the HTFP may be adapted for processing dental payments,processing payments from customers (e.g., Home Depot) to suppliers(e.g., hammer manufacturers), and/or the like. While various embodimentsand discussions of the HTFP have included payment platforms, however, itis to be understood that the embodiments described herein may be readilyconfigured and/or customized for a wide variety of other applicationsand/or implementations.

1.-21 (canceled)
 22. A payment processing processor-readable, non-transient medium, the medium storing a component collection, the component collection storage structured with processor-executable instructions comprising: receive a payment settling request datastructure via the payment settling component; determine, via processor, an ACH CCD+ payment amount and an ACH CCD+ re-association trace number by parsing the payment settling request, wherein the re-association trace number links an EFT payment with an EOP data file; and provide, via a network, an ACH CCD+ payment request; obtain a request to generate a payment card datastructure associated with the ACH CCD+ payment request to a provider via the card generating component via a network, wherein the request to generate a payment card datastructure is a request configured to generate the creation of a new payment card, and wherein the new payment card is any of: debit card, credit card, virtual debit card, virtual credit card, reloadable debit card, one-time credit card, one-time debit card; determine, via processor, a payment amount and a re-association trace number by parsing the card generation request; generate, via processor, a payment card datastructure for the payment; associate, via processor, the payment card datastructure with the payment amount and the re-association trace number; and send, via processor, a card payment processing request associated with the card; obtain the card payment processing request via the card payment processing component; generate, via processor, a Level 3 card payment request datastructure, wherein the Level 3 card payment request datastructure includes the payment amount and the re-association trace number; determine, via processor, a payment request route associated with the card; and pushing, via a network, the Level 3 card payment request datastructure via the determined payment request route.
 23. The medium of claim 22, further, comprising: configure the payment card datastructure to be usable with a specified set of allowed Merchant Category Codes.
 24. The medium of claim 22, wherein the payment card datastructure involves a single use card.
 25. The medium of claim 24, wherein generating the payment card datastructure includes generating a card number, a CVV, and an expiration date for the card.
 26. The medium of claim 22, wherein the payment card datastructure involves a reloadable card.
 27. The medium of claim 26, wherein generating the payment card datastructure includes generating a card number, a CVV, and an expiration date for the card.
 28. The medium of claim 27, wherein generating the payment card datastructure includes incrementing the CVV for a card to generate a unique identifier for the payment.
 29. The medium of claim 27, wherein generating the payment card datastructure includes incrementing the expiration date for a card to generate a unique identifier for the payment.
 30. The medium of claim 22, wherein the payment request route is one of: an acquirer, a payment network, and a virtual terminal.
 31. The medium of claim 22, wherein the Level 3 card payment request datastructure is sent from an issuer's server to a payment network's server.
 32. The medium of claim 22, wherein the Level 3 card payment request datastructure is sent from an issuer's server to an acquirer's server.
 33. The medium of claim 32, wherein the acquirer's server calculates an interchange rate associated with a card based on the provider's merchant identifier.
 34. The medium of claim 32, wherein the issuer and the acquirer are the same entity.
 35. The medium of claim 22, further, comprising: calculate an interchange rate associated with a card based on the provider's merchant identifier.
 36. The medium of claim 22, wherein send, via a network, an ACH CCD+ payment request, wherein the ACH CCD+ payment request includes the ACH CCD+ payment amount and the ACH CCD+ re-association trace number.
 37. The medium of claim 36, wherein the ACH CCD+ payment amount is the payment amount less a fee, and wherein the ACH CCD+ re-association trace number is the re-association trace number.
 38. The medium of claim 36, further, comprising: update the provider's virtual terminal with details regarding the payment, wherein the details include the ACH CCD+ payment amount and the ACH CCD+ re-association trace number.
 39. The medium of claim 22, further, comprising: an EOP file delivering component in the component collection, and select an EOP file associated with the re-association trace number; determine the provider's EOP file delivery preferences; and deliver the EOP file per the provider's EOP file delivery preferences.
 40. The medium of claim 39, wherein the EOP file delivery preferences include one of: FTP, email, clearinghouse, and provider pick-up.
 41. The medium of claim 39, wherein the EOP file is delivered within a specified time of the card generation request being sent.
 42. The medium of claim 22, wherein the payment is one of the plurality of payments in a batch of payments that are processed in aggregate.
 43. A payment processing processor-implemented system, comprising: means to store a component collection; means to process processor-executable instructions from the component collection, the component collection storage structured with processor-executable instructions including: receive a payment settling request datastructure via the payment settling component; determine, via processor, an ACH CCD+ payment amount and an ACH CCD+ re-association trace number by parsing the payment settling request, wherein the re-association trace number links an EFT payment with an EOP data file; and provide, via a network, an ACH CCD+ payment request; obtain a request to generate a payment card datastructure associated with the ACH CCD+ payment request to a provider via the card generating component via a network, wherein the request to generate a payment card datastructure is a request configured to generate the creation of a new payment card, and wherein the new payment card is any of: debit card, credit card, virtual debit card, virtual credit card, reloadable debit card, one-time credit card, one-time debit card; determine, via processor, a payment amount and a re-association trace number by parsing the card generation request; generate, via processor, a payment card datastructure for the payment; associate, via processor, the payment card datastructure with the payment amount and the re-association trace number; and send, via processor, a card payment processing request associated with the card; obtain the card payment processing request via the card payment processing component; generate, via processor, a Level 3 card payment request datastructure, wherein the Level 3 card payment request datastructure includes the payment amount and the re-association trace number; determine, via processor, a payment request route associated with the card; and pushing, via a network, the Level 3 card payment request datastructure via the determined payment request route.
 44. The system of claim 43, further, comprising: configure the payment card datastructure to be usable with a specified set of allowed Merchant Category Codes.
 45. The system of claim 43, wherein the payment card datastructure involves a single use card.
 46. The system of claim 45, wherein generating the payment card datastructure includes generating a card number, a CVV, and an expiration date for the card.
 47. The system of claim 43, wherein the payment card datastructure involves a reloadable card.
 48. The system of claim 47, wherein generating the payment card datastructure includes generating a card number, a CVV, and an expiration date for the card.
 49. The system of claim 48, wherein generating the payment card datastructure includes incrementing the CVV for a card to generate a unique identifier for the payment.
 50. The system of claim 48, wherein generating the payment card datastructure includes incrementing the expiration date for a card to generate a unique identifier for the payment.
 51. The system of claim 43, wherein the payment request route is one of: an acquirer, a payment network, and a virtual terminal.
 52. The system of claim 43, wherein the Level 3 card payment request datastructure is sent from an issuer's server to a payment network's server.
 53. The system of claim 43, wherein the Level 3 card payment request datastructure is sent from an issuer's server to an acquirer's server.
 54. The system of claim 53, wherein the acquirer's server calculates an interchange rate associated with a card based on the provider's merchant identifier.
 55. The system of claim 53, wherein the issuer and the acquirer are the same entity.
 56. The system of claim 43, further, comprising: calculate an interchange rate associated with a card based on the provider's merchant identifier.
 57. The system of claim 43, wherein send, via a network, an ACH CCD+ payment request, wherein the ACH CCD+ payment request includes the ACH CCD+ payment amount and the ACH CCD+ re-association trace number.
 58. The system of claim 57, wherein the ACH CCD+ payment amount is the payment amount less a fee, and wherein the ACH CCD+ re-association trace number is the re-association trace number.
 59. The system of claim 57, further, comprising: update the provider's virtual terminal with details regarding the payment, wherein the details include the ACH CCD+ payment amount and the ACH CCD+ re-association trace number.
 60. The system of claim 43, further, comprising: an EOP file delivering component in the component collection, and select an EOP file associated with the re-association trace number; determine the provider's EOP file delivery preferences; and deliver the EOP file per the provider's EOP file delivery preferences.
 61. The system of claim 60, wherein the EOP file delivery preferences include one of: FTP, email, clearinghouse, and provider pick-up.
 62. The system of claim 60, wherein the EOP file is delivered within a specified time of the card generation request being sent.
 63. The system of claim 43, wherein the payment is one of the plurality of payments in a batch of payments that are processed in aggregate.
 64. A payment processing process, including processing processor-executable instructions via at least one processor from a component collection stored in at least one memory, the component collection storage structured with processor-executable instructions comprising: receive a payment settling request datastructure via the payment settling component; determine, via processor, an ACH CCD+ payment amount and an ACH CCD+ re-association trace number by parsing the payment settling request, wherein the re-association trace number links an EFT payment with an EOP data file; and provide, via a network, an ACH CCD+ payment request; obtain a request to generate a payment card datastructure associated with the ACH CCD+ payment request to a provider via the card generating component via a network, wherein the request to generate a payment card datastructure is a request configured to generate the creation of a new payment card, and wherein the new payment card is any of: debit card, credit card, virtual debit card, virtual credit card, reloadable debit card, one-time credit card, one-time debit card; determine, via processor, a payment amount and a re-association trace number by parsing the card generation request; generate, via processor, a payment card datastructure for the payment; associate, via processor, the payment card datastructure with the payment amount and the re-association trace number; and send, via processor, a card payment processing request associated with the card; obtain the card payment processing request via the card payment processing component; generate, via processor, a Level 3 card payment request datastructure, wherein the Level 3 card payment request datastructure includes the payment amount and the re-association trace number; determine, via processor, a payment request route associated with the card; and pushing, via a network, the Level 3 card payment request datastructure via the determined payment request route.
 65. The process of claim 64, further, comprising: configure the payment card datastructure to be usable with a specified set of allowed Merchant Category Codes.
 66. The process of claim 64, wherein the payment card datastructure involves a single use card.
 67. The process of claim 66, wherein generating the payment card datastructure includes generating a card number, a CVV, and an expiration date for the card.
 68. The process of claim 64, wherein the payment card datastructure involves a reloadable card.
 69. The process of claim 68, wherein generating the payment card datastructure includes generating a card number, a CVV, and an expiration date for the card.
 70. The process of claim 69, wherein generating the payment card datastructure includes incrementing the CVV for a card to generate a unique identifier for the payment.
 71. The process of claim 69, wherein generating the payment card datastructure includes incrementing the expiration date for a card to generate a unique identifier for the payment.
 72. The process of claim 64, wherein the payment request route is one of: an acquirer, a payment network, and a virtual terminal.
 73. The process of claim 64, wherein the Level 3 card payment request datastructure is sent from an issuer's server to a payment network's server.
 74. The process of claim 64, wherein the Level 3 card payment request datastructure is sent from an issuer's server to an acquirer's server.
 75. The process of claim 74, wherein the acquirer's server calculates an interchange rate associated with a card based on the provider's merchant identifier.
 76. The process of claim 74, wherein the issuer and the acquirer are the same entity.
 77. The process of claim 64, further, comprising: calculate an interchange rate associated with a card based on the provider's merchant identifier.
 78. The process of claim 64, wherein send, via a network, an ACH CCD+ payment request, wherein the ACH CCD+ payment request includes the ACH CCD+ payment amount and the ACH CCD+ re-association trace number.
 79. The process of claim 78, wherein the ACH CCD+ payment amount is the payment amount less a fee, and wherein the ACH CCD+ re-association trace number is the re-association trace number.
 80. The process of claim 78, further, comprising: update the provider's virtual terminal with details regarding the payment, wherein the details include the ACH CCD+ payment amount and the ACH CCD+ re-association trace number.
 81. The process of claim 64, further, comprising: an EOP file delivering component in the component collection, and select an EOP file associated with the re-association trace number; determine the provider's EOP file delivery preferences; and deliver the EOP file per the provider's EOP file delivery preferences.
 82. The process of claim 81, wherein the EOP file delivery preferences include one of: FTP, email, clearinghouse, and provider pick-up.
 83. The process of claim 81, wherein the EOP file is delivered within a specified time of the card generation request being sent.
 84. The process of claim 64, wherein the payment is one of the plurality of payments in a batch of payments that are processed in aggregate. 